link-it
Utilizzo regole di trasformazione dei messaggi
Buongiorno, ho configurato una erogazione con profilo MODI (INTEGRITY_REST_01 con AUTH_REST_01) e token negoziato con la PDND. E' possibile tramite una trasformazione manipolare il contenuto delle response fornite da govway in modo da rispettare quanto descritto nel descrittore openapi? Faccio un esempio: nel caso di richiesta verso l'eservice senza token jwt, govway risponde con una response http di questo tipo: http response code: 401 body: { "type": "https://govway.org/handling-errors/401/TokenAuthenticationRequired.html", "title": "TokenAuthenticationRequired", "status": 401, "detail": "A token is required", "govway_id": "a10c5e47-f5b6-11ef-944d-0242ac120013" }
è possibile in questo caso eseguire la trasformazione per avere un body di questo tipo: { "message": "PDND token not found", "code": "ERROR_401_001" }
Grazie per ogni suggerimento
Buongiorno @fabricorse .
Una trasformazione della risposta consente solo di modificare le risposte ritornate dal backend.
Gli errori generati da GovWay vengono restituiti al client nel formato standard RFC 7807 richiesto dalle Linee Guida di Interoperabilità - Raccomandazioni di Implementazione - RAC_REST_NAME_008 e vengono generati, come nel caso da te riportato, prima di invocare il backend.
Per attuare una modifica dell'errore ritornato al client, in modo da restituire la struttura json indicata non conforme alle Linee Guida, potresti avventurarti nell'implementazione di una classe java che implementa delle interfacce 'message handler' disponibili nel pipeline di gestione delle richieste in GovWay.
Si tratta di una funzionalità non documentata accessibili tra le opzioni avanzate di una erogazione o fruizione di API. Gli handler devono essere registrati accedendo alla sezione 'Configurazione - Generale - Registro Classi' dove è possibile censire la classe java realizzata come 'Message Handler' e la classe deve essere poi disponibile nel classloader dell'applicazione.
Anche io avrei un'esigenza simile. Qualora mi volessi avventurare nell'implementazione di una classe per questo tipo di necessità, visto che non c'è documentazione a riguardo, esiste una classe d'esempio da usare come punto di partenza?
Buongiorno @ninolcr.
Essendo una funzionalità non documentata non esistono classi di esempio. All'interno del progetto puoi trovare classi che implementano le interfacce degli handlers.
Salve, ho scaricato e stavo provando a compilare il progetto ma eseguendo le istruzioni nel README.compile la compilazione fallisce. Ho installato sia la jdk 11 che maven, bisogna configurare altro oltre quello che è scritto nella guida?
Buongiorno @ninolcr .
Windows non è l’ambiente di riferimento per la compilazione del software: consigliamo di utilizzare una macchina Linux.
Detto ciò, i file che vanno in errore sono link simbolici.
Controlla i path che causano errore e, se necessario, sostituiscili con quelli originali.
Buongiorno, grazie per i suggerimenti, siamo riusciti a configurare un ambiente di sviluppo. Dovendo implementare quindi l'interfaccia org.openspcoop2.pdd.core.handlers.OutResponseHandler, come possiamo generare i jar da caricare all'interno di govway?
Grazie in anticipo.
Buongiorno @ninolcr
L’implementazione dell’interfaccia org.openspcoop2.pdd.core.handlers.OutResponseHandler può essere gestita tramite un progetto autonomo di vostra gestione, che includa anche la generazione del relativo jar.
I jar di GovWay, da utilizzare come dipendenze nel vostro progetto, possono essere ottenuti seguendo le istruzioni di compilazione riportate nel README.compile. Al termine della compilazione, tutti i jar generati saranno disponibili nella sottodirectory dist della directory di lavoro.
Una volta generato, l’archivio jar contenente l’handler dovrà essere reso disponibile nel classloader di GovWay, ad esempio copiandolo nella directory lib all’interno dell’archivio govway.ear.
Buonasera, Grazie, con il tuo suggerimento siamo riusciti a creare un progetto per un message handler che implementa l'interfaccia org.openspcoop2.pdd.core.handlers.OutResponseHandler. Avremo bisogno però di recuperare alcune informazioni dall'header della richiesta per inserirne altre che dipendono da queste nella response in caso di specifici errori. è possibile? nel caso puoi suggerirci come?
Grazie ancora per il supporto.
Buonasera @ninolcr .
l'handler SUAPResponseGenerator, riferito nella documentazione Adeguamento al formato di errori previsto dai servizi del SUAP, dovrebbe implementare quanto ti serve. L'handler sarà fornito built-in a partire dalla prossima versione.
Buongiorno @andreapoli , grazie mille! l'handler è esattamente quello di cui abbiamo bisogno. Stiamo già testando l'utilizzo dell'handler ma facendo qualche prova di utilizzo sembrerebbe che nel caso in cui non venga passato il token Agid-JWT-Signature si continua a ricevere la risposta di default del gateway
{
"type": "https://govway.org/handling-errors/400/InteroperabilityInvalidRequest.html",
"title": "InteroperabilityInvalidRequest",
"status": 400,
"detail": "Received request is not conform to the required interoperability profile",
"govway_id": "26a2cc44-5b2b-11f0-b35d-027a4b83c7cb"
}
anzichè quella prevista :
{
"message": "AgID-JWT-Signature token not found",
"code": "ERROR_401_003"
}
Buongiorno @ninolcr .
L'handler è stato verificato sul master come puoi vedere dalla presenza della testsuite di riferimento.
La vostra richiesta non rientra tra i casi presenti nella testsuite? Nel caso puoi allegare l'export della transazione comprensiva di contenuti e header http?
Buon pomeriggio, Si il caso di test era presente, credo di aver capito però quale sia il problema:
Nel nostro caso stiamo configurando una erogazione di un api con un "custom-JWT-Signature" :
Quindi nel momento in cui l'header non è presente non soddisfa la condizione presente nell'handler :
#if(desc!=null && "Header HTTP 'Agid-JWT-Signature' non presente".equals(desc)) { casoAgitJWTSignatureNonPresente = true; }
Buonasera @ninolcr
a cosa è dovuto la scelta di utilizzare un nome custom ?
Buongiorno @andreapoli , abbiamo avuto modo di verificare che dai report della suite di test blacbox viene passato con quell'header.
Buongiorno @ninolcr ,
Scaricando il 'Manuale Operativo BlackBox test con welcome kit' dalla documentazione ufficiale disponibile sulla PDND non sembrerebbe.
Nel documento interno 'Manuale operativo SBBT_v1.pdf' è presente la seguente frase:
E anche nel documento interno 'SUAP BB Test_v2.16.xlsx' tutti gli esempi di tracciato riportano il nome del token ufficiale.
Avete una specifica di riferimento dove viene descritto l'utilizzo di un nome differente ?
Abbiamo visto che veniva denominato con quel nome nei report di risposta della bbt, tuttavia abbiamo avuto conferma che le chiamate dovrebbero avvenire con la corretta nomenclatura indicata dalle specifiche, quindi con Agid-JWT-Signature.
Grazie mille
@andreapoli Abbiamo avuto modo di cominciare a provare la suite di test blacbox usando l'handler da voi fornito, tuttavia abbiamo degli errori da parte della black box, nel caso in cui le response di tipo 400 o 401 siano generate dal gateway tramite l'handler. Dagli errori che riceviamo sembrerebbe che sia necessario anche fornire l'agid-jwt-signature nelle response di errore. Come possiamo configurare questo comportamento?
Buongiorno @ninolcr
Per ovvi motivi di affidabilità della piattaforma, GovWay non produce token di integrity per messaggi scartati, come ad esempio i messaggi privi di token PDND. Il risultato atteso per i servizi del SUAP può essere comunque ottenuto con un'ulteriore erogazione in cascata, ma è una soluzione inadeguata per un'installazione in produzione, obbligando GovWay a produrre token firmati per richieste non valide che potrebbero arrivare da chiunque. Questo problema relativo alle specifiche non è stato sollevato da nessuno?
Buongiorno @andreapoli, Sinceramente non so ma io sto riscontrando questa problematica, volendo fare una prova temporanea in ambiente di sviluppo con un erogazione in cascata, anche per capire se si riscontrano altre problematiche oltre quella descritta, immagino sia necessario fare il forwarding di entrambi gli header (Authorization e Agid-jwt-signature) all'erogazione "interna", come potrebbe essere configurato questo comportamento?
Buongiorno @ninolcr
Abbiamo predisposto delle govlet pensate per semplificare la configurazione dei servizi. Ti condivido un’anteprima relativa al gruppo 'FO-to-...', corredata dal materiale allegato:
Una volta caricato l'archizio zip SUAP-FO-to-Test_v1.zip tramite la funzionalità Importa e completati tutti gli step previsti dal Wizard, verranno generate automaticamente quattro erogazioni per i due servizi FO-to-BO e FO-to-CU. Analizzando queste configurazioni, potrai osservare come sia possibile realizzare una configurazione a cascata, in grado di soddisfare i requisiti previsti per la certificazione SUAP.
Grazie mille @andreapoli, ho provato le govlet per il gruppo FO-to.. riuscendo a configurare quindi le relative erogazioni, tuttavia volevo segnalare che replicando i test della suite si hanno due problematiche:
la suite genera alcune chiamate GET con all'interno un token integrity in cui sono presenti due header firmati :
la presenza dell'header "content-type : null" tra gli header firmati fa generare al gateway l'errore :
{
"code": "ERROR_401_004",
"message": "invalid AgID-JWT-Signature token"
}
la seconda problematica riguarda invece i casi di test in cui viene passato un header Authorization con un token errato (non bearer) , la suite di test in questi casi si aspetta un errore del tipo :
{
"code" : "ERROR_401_002",
"message" : "Invalid PDND token"
}
in realtà il gateway genera un errore del tipo :
{
"code": "ERROR_401_001",
"message": "PDND token not found"
}
Buonasera @ninolcr,
per quanto concerne la seconda problematica è un'anomalia nota che è stata risolta nei commit ca3428e28b6450dec232c346927a927bc2d098e1 (versione 3.4.x) e 52ea80bf0b08e260fe88037248368b8e645c22b3 (versione 3.3.x) e verrà inclusa nella prossima versione.
Invece per quanto riguarda la prima, ii token di integrity della richiesta indica tra gli header firmati il campo content-type con valore null, ma la richiesta non contiene l’header content-type. In ogni caso nelle GET l’header content-type non è previsto, nemmeno con valore null. Andrebbe quindi richiesta una correzione lato black-box.
Buongiorno @andreapoli, Grazie mille per le informazioni. Proveremo a chiedere una correzione per quanto riguarda il problema del content-type. Per quanto riguarda l'altro fix è previsto a breve un rilascio della versione 3.3.18 con questa correzione?
Buongiorno @ninolcr
Stiamo terminando alcune sperimentazioni da includere nella prossima versione. Non appena completate scheduleremo un rilascio.
Come workaround in attesa di un prossimo rilascio potresti utilizzare la classe riferita nel commit https://github.com/link-it/govway/commit/52ea80bf0b08e260fe88037248368b8e645c22b3 compilandola e sostituendola all'interno dell'archivio jar openspcoop2_pdd-<version>.jar presente nell'archivio govway.ear.