inad_api_extraction's People
inad_api_extraction's Issues
Richiesta di esempio pratico chiamata extract nella documentazione
buongiorno,
Sto effettuando le prime chiamate alla ws /extract
ma mi ritorna sempre errore 400 bad request
mi sarebbe comodo avere una chiamata di esempio raw a cui fare riferimento per costruire bene la chiamata.
la chiamata che faccio e' questa:
GET /rest/inad/v1/domiciliodigitale/extract/MNCDVD96E28B519P HTTP/1.1
Authorization: Bearer eyJ0eXAiOixxxx.eyJhdWQxxxxxx
Host: domiciliodigitaleapi.oscl.infocamere.it
mi sembra di fare tutto correttamente tranne una cosa, nella documentazione ce scritto che bisogna passare in query il practicalReference, ma dentro la chiamata come deve essere inserito?
Error 401 "Invalid Bearer JWT Token" durante la richiesta a INAD
Ciao,
sono uno sviluppatore che si sta occupando dell'integrazione INAD su un applicativo della nostra azienda.
Siamo su collaudo e stiamo utilizzando l'e-service INAD API PUBBLICHE CONSULTAZIONE.
Per soddisfare la nostra richiesta abbiamo fatto generare in primo luogo la chiave privata, utile a generare l'assertion (assertion key ha passato con successo i controlli del debug) che chiamando https://auth.uat.interop.pagopa.it/token.oauth2. riesce a farci ottenere il token da utilizzare per la chiamata al servizio INAD.
"client_id": "dd7b1ac0-0c84-4557-88e1-1c8f7a15e061"
"jti": "d32abdb8-a508-4196-9442-e4cb306ead5f"
Per la chiamata al sevizio INAD (https://api.inad.gov.it/rest/inad/v1/domiciliodigitale/extract/RRANGL74M28R701V?practicalReference=asd) aggiungiamo nell'header Authorization: Bearer <(token ottenuto nella chiamata precedente)> (come da guida) e come risposta otteniamo il seguente errore:
{
"status": 401,
"type": "UNAUTHORIZED",
"detail": "Invalid Bearer JWT Token"
}
Guide utilizzate:
Generazione dell'assertion e successivo token
Richiesta a INAD
Chiediamo supporto a riguardo e siamo reperibili in ogni modo per risolvere il problema
Errore 500
Salve,
da pochi giorni, utilizzando il servizio d'estrazione ricevo il seguente errore:
{"timestamp":"2023-10-03T10:34:45.654+00:00","status":500,"error":"Internal Server Error","path":"/v1/domiciliodigitale/extract/TRVVCN73H02L259I"}
Ho effettuato la verifica per l'assertion con il tool messo a disposizione della piattaforma e mi dà esito positivo.
L'endpoint utilizzato per la richiesta è il seguente:
https://domiciliodigitaleapi.oscl.infocamere.it/rest/inad/v1/domiciliodigitale/extract/TRVVCN73H02L259I?practicalReference=testdeda
possibili soluzioni?
Grazie in anticipo
Errore 404
Buongiorno,
utilizzando i servizi, ricevo errore 404 "CF not found", sia che uso codici fiscali validi, sia che li uso non validi... ci sarebbero dei CF di test da poter utilizzare?
Grazie
Intervallo per polling
Ci sono indicazioni per impostare un intervallo di tempo congruo per il polling su /listDigitalAddress/state/{id} dello stato di avanzamento di una richiesta multipla?
Riferimento, "Documento operativo ModI su pattern di interazione", paragrafo 5.2 (Pattern non bloccanti RPC PULL (busy waiting)):
"Gli intervalli di polling possono essere definiti tra le parti."
recuperoDomicilioDigitale - practicedProfession sempre a null
Sto testando il metodo recuperoDomicilioDigitale : GET /extract/{codice_fiscale}
Tra i campi di risposta ho 'practicedProfession '
"La valorizzazione di practicedProfession è prevista solo per la fattispecie “professionisti che svolgono una professione non organizzata in ordini, albi o collegi ai sensi della legge n. 4/2013 (di seguito Professionisti)”.
Ho provato con vari codici fiscali di professionisti (Avvocati, Geometri, etc.) ma il campo 'practicedProfession ' è sempre null.
Avreste almeno un codice fiscale per testare il practicedProfession?
Grazie
RISOLTO - Trust fra fruitore ed erogatore
Il README qui su GitHub menziona la PDND come intermediario per stabilire il trust fra erogatore e fruitore.
La PDND non è mai menzionata nelle specifiche tecniche delle API: https://domiciliodigitale.gov.it/dgit/home/public/docs/inad-specifiche_tecniche_api_estrazione.pdf
Le specifiche pero' ai paragrafi 4.2 e 4.3 descrivono un processo che è del tutto simile a quello che si fa su PDND per ottenere il token JWT da spendere nell'header delle chiamate all'e-service.
Si deve intendere che quanto descritto ai paragrafi 4.2. e 4.3 si fa con la PDND?
Esito di alcune prove (RISOLTO)
A scopo puramente didattico e di orientamento, sto facendo alcune prove dei servizi di estrazione, utilizzando degli script Python (disponibili in un mio repository non ancora pubblicato, posso invitare come collaborator se utile).
L'interazione funziona, però segnalo alcuni fatti.
Premetto che non so se in ambiente di test ci sono CF e indirizzi registrati, quindi ho utilizzato o dati miei o dati del tutto inventati (anche formalmente non corretti). Non ho quindi mai ricevuto response con status 200 (eccezione fatta per il messaggio di chiusura serale :) )
Segnalo:
- sia con /extract/ sia con /verify/ non mi pare ci siano controlli sulla correttezza formale né del codice fiscale né della data né dell'indirizzo mail da verificare;
- infatti, inserendo una request con parametri del tipo 'codice_fiscale' : 'aaa', 'since' : '2023-31-31' o 'since' : '2023', ricevo comunque una response con status code 404 (not found) mentre ci si potrebbe attendere una 400 (bad request)
- lo stesso se nei parametri della chiamata a /verify/{cf} ometto uno dei paramenti marcati come obbligatori nelle specifiche yaml, per esempio 'digital_address', di nuovo response con status code 404.
OffTopic (solo in parte)
I servizi di consultazione di INI-PEC sono attualmente erogati da InfoCamere su Porta di Dominio.
Quando saranno disponibili secondo il nuovo modello di interoperabilità?
Semantica parametro practicalReference
Buongiorno,
al fine di riuscire ad utilizzare propriamente le API offerte da INAD, chiederei cortesemente di specificare più chiaramente il significato del parametro practicalReference
, presente nelle varie GET.
In particolare,
- non è chiaro se sia atteso un valore particolare che faccia riferimento al "numero di protocollo" della pratica da notificare o, per esempio, sia una sorta di "costante" da utilizzare per indicare la tipologia di procedimento che ha portato alla necessità di richiedere il domicilio digitale
- non è chiaro se sia presente una qualche verifica del suddetto parametro lato INAD (e quali siano le eventuali logiche di controllo)
Rimanendo a disposizione per eventuali ulteriori chiarimenti sulla richiesta, si attende cortese riscontro.
Cordiali Saluti
verificaDomicilioDigitale - Bad Request
Nello yaml ho le seguenti definizioni :
Digital_Address:
pattern: ^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+.[a-zA-Z0-9-.]+$
type: string
description: Indirizzo PEC del Domicilio Digitale
example: [email protected]
UUID:
maxLength: 40
minLength: 20
pattern: ^[{]?[0-9a-fA-F]{8}-([0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}[}]?$
type: string
description: Codice univoco della richiesta di elaborazione Report
example: f8c3de3d-1fea-4d7c-a8b0-29f63c4c3454
Sto testando il metodo verificaDomicilioDigitale tramite il client (generato dallo yaml).
Viene fatta una GET in questo modo :
https://api.inad.gov.it/rest/inad/v1/domiciliodigitale/verify/CIOFBA80B29D810R?digital_address=fcioe%252540pecagrotecnici.it&since=2017-07-21&practicalReference=test
Il client effettua in automatico un encode del "digital_address" ad UTF-8 (credo sia corretto) ma il pattern (tramite le RegEx) poi lo rifiuta ed ottengo una BAD REQUEST (a causa della @ codificata)
Se da Postman faccio una GET secca senza "encode" dei campi, funziona.
https://api.inad.gov.it/rest/inad/v1/domiciliodigitale/verify/[email protected]&since=2017-07-21&practicalReference=test
Non ne sono certo ma almeno per le email e lo uuid si possono usare i relativi format
Specifiche OpenAPI : https://spec.openapis.org/registry/format/
Un po' come è stato già fatto qui nello yaml :
dateTimeCheck:
type: string
description: Data/Ora estrazione in formato ISO 8601 <yyyy-MM-dd'T'HH:mm:ssZ>
format: date-time
example: '2017-07-21T17:32:28Z'
Fatemi sapere se è un bug o una gestione NON corretta da parte mia (anche se il client che è autogenerato a partire dallo yaml)
Grazie
Errore Token su qualsiasi chiamata
Buonasera,
stiamo provando ad effettuare una chiamata con Postman al servizio INAD in ambiente di interoperabilità collaudo.
Abbiamo effettuato la connessione nel sistema di interoperabilità collaudo e ottenuto il corretto client_assertion (verificato anche tramite il degub presente all'interno dell'interoperabilità)
Fatto questo, tramite l'API https://auth.uat.interop.pagopa.it/token.oauth2 abbiamo ottenuto il token per l'e_service INAD API PUBBLICHE CONSULTAZIONE.
Quando effettuiamo una qualsiasi chiamata ai servizi esposti su https://api.inad.gov.it/rest/inad/v1/domiciliodigitale otteniamo in risposta {"status":401,"type":"UNAUTHORIZED","detail":"Invalid Bearer JWT Token"}.
Dove stiamo sbagliando? C'è qualche ulteriore configurazione non riportata nella guida?
Segnalo inoltre che la guida, pur essendo uno yalm, non è leggibile con swagger.
Allego un dettaglio della chiamata.
POST https://api.inad.gov.it/rest/inad/v1/domiciliodigitale/listDigitalAddress
401
82 ms
POST /rest/inad/v1/domiciliodigitale/listDigitalAddress HTTP/1.1
Content-Type: application/json
Accept: application/json
Authorization: Bearer eyJ0eXAiOiJhdCtqd3QiLCJhbGciOiJSUzI1NiIsInVzZSI6InNpZyIsImtpZCI6IjMyZDhhMzIxLTE1NjgtNDRmNS05NTU4LWE5MDcyZjUxOWQyZCJ9.eyJhdWQiOiJkb21pY2lsaW9kaWdpdGFsZWFwaS5vc2NsLmluZm9jYW1lcmUuaXQiLCJzdWIiOiI1ZmQ2N2JiYi04ZGQ0LTQ4NjUtODAzMi1iYjQ0MzExNWRiNTIiLCJuYmYiOjE3MDM4NTY4MzksInB1cnBvc2VJZCI6IjI4N2IzZWNhLWMwZDMtNDQzZS05MTU0LTUxNGVlZDMxMmI5MCIsImlzcyI6InVhdC5pbnRlcm9wLnBhZ29wYS5pdCIsImV4cCI6MTcwMzk0MzIzOSwiaWF0IjoxNzAzODU2ODM5LCJjbGllbnRfaWQiOiI1ZmQ2N2JiYi04ZGQ0LTQ4NjUtODAzMi1iYjQ0MzExNWRiNTIiLCJqdGkiOiIzNGFkMTIyMS1kZTc5LTRiMDgtODY5Ny0yNmZhZDBlNmY3MzYifQ.DVg8MokPyaal2igBW1s8l0D0klecq60d-ruWNHxdfhbiKB1GgHbsOMRkdxL6sC-hZogvDO9HYBS708DOvgL3GIH5iQJ-yWjs6Qqz69Oe7BiQQ5rJkLQqGBH5N8TfUC_WxjfzgGIdlyf06uUU-K6qCT8uUjAa2tCPqUKDaOyGE5J90oxJrvRNY5GY50VV5sTBEV4opAjk9PQdfMBww28t8bvOam2c_NlUbYnlTa0pK-4svu7M-toVndeF0e7B7iH3AJxL3mWi4rIcqOZE1jZhwCrt5eLwvYQq9MPQgd9I4dw7KSKtYrumn0DQsbw8Gzy9DL-zcn_aBvA8QAhNGZ4Fkw
User-Agent: PostmanRuntime/7.36.0
Postman-Token: b94af0a0-b26e-4288-93a0-584a3dd1c83a
Host: api.inad.gov.it
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 82
Cookie: 34c274f102110c314e7714720f9f288f=d3d61b9c138776e793e708bf15aa1cae
{
"codiciFiscali": [
"RGGSNO93E57C619T"
],
"praticalReference": "1234"
}
HTTP/1.1 401 Unauthorized
Content-Type: application/json
Content-Length: 72
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
X-XSS-Protection: 1 ; mode=block
Referrer-Policy: no-referrer
connection: close
{"status":401,"type":"UNAUTHORIZED","detail":"Invalid Bearer JWT Token"}
Errore servizio
Buongiorno,
ricevo l'errore 401 "Unauthorized" dai servizi, ho provato a contattare PDND ma dal loro lato mi confermato vada tutto a buon fine. Sono in fase di collaudo, l'e-service che sto utilizzando è "INAD API PUBBLICHE CONSULTAZIONE", perchè "INAD CONSULTAZIONE DD" non mi risulta nel catalogo di collaudo, quale potrebbe essere il problema?
Cordiali saluti.
Verifica del domicilio digitale senza codice fiscale: richiesta di evoluzione
Proposta: consentire di reperire informazioni su registrazione e titolare di un domicilio digitale senza fornire il codice fiscale.
Caso d'uso:
- l'art 65 c. 1 lett. c-bis del CAD prevede che l'istanza e la comunicazione inviate dal domicilio digitale registrato nei 3 registri (INAD, INIPEC, IPA) è valida (anche se non provvista di firma digitale, cioè);
- questo rende necessario verificare che la casella certificata da cui si riceve il messaggio sia domicilio digitale registrato dell'autore di istanza o comunicazione;
- siamo fuori da una procedura di presentazione di istanze guidata, quindi il sistema (protocollo informatico, direi) che riceve il messaggio non ha il codice fiscale del mittente come dato strutturato, non è quindi possibile invocare un automatismo per verificare se la casella mittente e' un domicilio digitale registrato dal mittente;
- un controllo semimanuale risulterebbe oneroso e disfunzionale (per via dei volumi) e talvolta impossibile (esistono casi in cui il mittente è chiaramente identificabile ma non se ne conosce il codice fiscale - ripeto, siamo in un contesto di trasmissione di documenti non guidata);
- invece, un controllo (anche da fare solo ed esclusivamente via API) che dall'indirizzo della casella fornisce riposta con codice fiscale (e magari nome e cognome) del titolare, potrebbe consentire di automatizzare la verifica se la casella mittente è un codice fiscale;
- la corrispondenza fra titolare del domicilio digitale e intestatario/autore dell'istanza/comunicazione può poi essere demandato a chi cura l'istruttoria del procedimento o le attività conseguenti.
Tempo di attesa molto altro per response elaborazione liste massive
Buon pomeriggio,
stiamo avendo problemi nell'interrogare, sull'ambiente di produzione, il servizio di richiesta massiva tramite pdnd.
Di fatto ogni giorno ci va a buon fine, e quindi con l.a response dei cf aventi o meno la pec, solo per la prima interrogazione. Le sucessive rimangono in stato IN_ELABORAZIONE anche dopo diverse ore.
Come esempio riporto le segiuenti interrogazioni massive eseguite in data odierna:
{
"state": "PRESA_IN_CARICO",
"message": "Richiesta elenco presa in carico",
"id": "c62e69b1-9d23-4649-b291-909815ae0cdb",
"dateTimeRequest": "2023-08-01T08:20:07Z"
}
la cui ressponse ha dato l'elenco richiesto nel giro di qualche minuto.
e le seguenti due:
{
"state": "PRESA_IN_CARICO",
"message": "Richiesta elenco presa in carico",
"id": "ed93ce97-3df6-4279-928a-0fa139ed3e20",
"dateTimeRequest": "2023-08-01T08:25:58Z"
}
e
{
"state": "PRESA_IN_CARICO",
"message": "Richiesta elenco presa in carico",
"id": "cc94aebf-cd9c-4f50-a554-0875983c1e8d",
"dateTimeRequest": "2023-08-01T08:56:21Z"
}
che ancora adesso (ore 16:46 del 01/08/23) hanno come state
{
"state": "IN_ELABORAZIONE",
"message": "Richiesta elenco in fase di processamento"
}
è possibile verificare da cosa dipende questa lunga attesa?
grazie
Servizio recupero stato di una lista - URL errata nel redirect
Salve,
ho fatto una prova con un'estrazione massiva : /listDigitalAddress e collegati.
Tutto bene, però rispetto alle specifiche:
- Con lista in stato "in elaborazione" ricevo lo status code atteso.
- quando la lista è pronta non ricevo una response con status code 303 ma con status code 404 (not found).
Poi il recupero della lista di domicili funziona.
Vi copio qualcosa che può essere utile:
Risposta a lista pronta:
"timestamp": "2023-06-15T17:40:14.600+00:00", "status": 404, "error": "Not Found", "path": "/v1/domiciliodigitale/elenco/3d271191-0d20-4693-8f5f-48ad49fcec9f/risultato"
Recupero della lista:
{ "list": [ { "codiceFiscale": "**************", "since": "2023-06-15T19:40:00Z", "digitalAddress": [ { "digitalAddress": "***@****.it" } ] }, { "codiceFiscale": "*********", "since": "2023-06-15T19:40:00Z", "digitalAddress": [ { "digitalAddress": "*****@***.it" } ] }, {
PS: ho ricevuto un elenco di codici fiscali censiti in ambiente di test dal supporto Infocamere, li ho oscurati.
OT? Estensione attributi
Buongiorno,
l'ente per il quale lavoro (società in-house) non presenta, su PDND, gli attributi richiesti per la fruzione dei servizi.
A chi è possibile chiedere l'esttensione degli attributi utilizzabili? Il supporto sul sito INAD non è stato in grado di fornire risposta.
Grazie, saluti
PP
Response 401 di verify e extract - "error" e non "detail"
I due metodi "verify" ed "extract", in caso di response con status code 401, restituiscono un payload con chiave "error" e non "detail" come invece scritto nelle specifiche OPENAPI (file .yaml)
Quanti domicili digitali?
Dalle linee guida AGID sembra evincersi che un soggetto possa avere al massimo due domicili digitali registrati su INAD.
Questo avviene solo nel caso in cui si iscriva e come professionista e come cittadino.
"Per quanto concerne l’elezione del domicilio digitale, solo i Professionisti hanno facoltà di eleggere nell’INAD sia un domicilio digitale professionale sia un domicilio digitale personale. La distinzione tra i due domicili digitali appartenenti al medesimo soggetto è resa evidente all’interno dell’INAD sia all’interessato, al momento dell’elezione del domicilio, sia agli utenti al momento della consultazione dell’INAD. "
Tuttavia uno dei CF presenti nell'ambiente di collaudo presenta ben tre domicili digitali associati.
Cosa ci si deve attendere in ambiente di produzione?
Invalid Bearer JWT Token
Buongiorno,
provando a invocare con postman in GET https://api.inad.gov.it/rest/inad/v1/domiciliodigitale/extract/{TRVVCN73H02L259I} ricevo sempre
{
"status": 401,
"type": "UNAUTHORIZED",
"detail": "Invalid Bearer JWT Token"
}
anche se ho generato correttamente il token JWT:
{
"access_token": "ey..........",
"expires_in": 600,
"token_type": "Bearer"
}
Sicuramente sbaglio qualcosa ma dopo diversi tentativi non sono riuscito a risolvere, potete aiutarmi?
Endpoint corretti e 401
Salve vorrei chiedere conferma dell'endpoint corretto da utilizzare per il metodo (es: verify) con dati provenienti dal csv di esempio:
https://domiciliodigitaleapi.oscl.infocamere.it/rest/inad/v1/domiciliodigitale/verify/MNTCRL93H18I452Y
oppure
https://api.inad.gov.it/rest/inad/v1/domiciliodigitale/verify/MNTCRL93H18I452Y
Inoltre la risposta è sempre di tipo 401.
Quale tipo di autenticazione è richiesta (presumo oauth2 con jwt) e come ottenete quindi tali credenziali.
Cordiali Saluti
consultazione delle API mediante stacco del JWT
Salve,
ho letto nelle LG del processo di trust ai paragrafi 4.1, 4.2 e 4.3, non conosco bene il processo simile che si effettua sulla PDND; vorrei capire chi è l'ente presso cui richiedere il voucher che emette i claim presente nel JWT da inserire poi nell'header delle richieste?
Il mio scopo sarebbe di utilizzare in un'architettura a microservizi delle chiamate REST ad alcune API presenti nello YML per recuperare la presenza di un DD a partire da un CF.
Mi scuso se la domanda può risultare pleonastica.
Grazie.
"Received fatal alert: handshake_failure" durante chiamata Rest verso INAD
Buongiorno,
sto provando ad implementare la chiamata REST verso INAD su Java 1.7.0_51 ma stiamo riscontrando un problema di handshake:
org.springframework.web.client.ResourceAccessException: I/O error on GET request for "[https://api.inad.gov.it/rest/inad/v1/domiciliodigitale/extract/GLLLSS87S05G838N":](https://api.inad.gov.it/rest/inad/v1/domiciliodigitale/extract/GLLLSS87S05G838N%22:) Received fatal alert: handshake_failure; nested exception is javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
Caused by: javax.net.ssl.SSLHandshakeException
Ho avuto lo stesso problema richiamando le API di PDND, ma ho risolto abilitando il TLS 1.2, in questo caso sembra che non è sufficiente.
Non ho letto nessuna specifica particolare riguardante i protocolli di sicurezza nella documentazione, potreste darmi delucidazioni a riguardo?
N.B.
abbiamo ancora il problema del 401 UNAUTHORIZED (#20) da Postman
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.