Esistenza in Vita C019 - errore in chiamata con GovWay

[sommafa]

Sto provando a chiamare il servizio in oggetto ma ottengo questo errore, è possibile sapere a cosa si riferisce?

{"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":"998ef0a5-c6a1-11ee-a130-005056ae1884"}

[sommafa]

buongiorno, si potrebbe avere un feedback sull'errore? dobbiamo sbloccare delle polizze e siamo bloccati

noi stiamo provando con questo payload:

{
  "idOperazioneClient": "1",

  "criteriRicerca": {
    "codiceFiscale": "DCLVNT58H11H501C"
  },
  "datiRichiesta": {
    "dataRiferimentoRichiesta": "2024-02-08",
    "motivoRichiesta": "1",
    "casoUso": "C019"
  }
}

[MPaoletti719]

https://github.com/italia/anpr/issues/3964#issuecomment-1767932441

[afrontera85]

Sto provando a chiamare il servizio in oggetto ma ottengo questo errore, è possibile sapere a cosa si riferisce?

{"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":"998ef0a5-c6a1-11ee-a130-005056ae1884"}

L'errore è il seguente: Validazione security token ModI 'INTEGRITY' della richiesta fallita: Riscontrate 2 eccezioni. Token con claim 'iat' non valido: Character array is missing "e" notation exponential mark. Token con claim 'exp' non valido: Character array is missing "e" notation exponential mark.

[sommafa]

grazie della risposta

c'è una cosa che non capisco, sto usando per i valori 'iat' ed 'exp' lo UnixTimeStamp come credo sai richiesto.

in .netCore: long now = DateTimeOffset.UtcNow.ToUnixTimeSeconds();

ma quindi un numero. Non capisco il messaggio di errore che indica che manca la notazione esponenziale.

Ho riprovato ora, ti allego il nuovo govway 4ffcb787-cc0c-11ee-a833-005056ae1884 mi dici se l'errore è sempre il medesimo?

grazie mille Fabio

[afrontera85]

Ecco l'errore: Validazione security token ModI 'INTEGRITY' della richiesta fallita: Header HTTP 'Digest' possiede un valore non corrispondente al messaggio

[sommafa]

Per chiarire, l'header Digest deve contenere la rappresentazione in Base64 dell'hash del body della request nella forma SHA-256='encoded body' è corretto?

o si sta riferendo a un altro digest?

[sommafa]

con questo govway 736473c3-cc10-11ee-a833-005056ae1884 l'errore è sempre sull'header digest?

[afrontera85]

l'errore è lo stesso. Mi aspetto come digest del body l'hash del body in base 64: MnQC1V0ad6TwPtw5mx1/9qpb/Q2m4P7LNYIU2QdqO3Y= ma arriva questo: LDZWixeGnHGbx3xqWMWvX+iYejver7xtcz8X8kf5yIo= Guardate il client di esempio nella issue #3964

[sommafa]

Stiamo usando il client di esempio come base.

Noi stiamo creando l'encoded body come nel codice nell'immagine. Alla riga 99, dopo aver generato l'hash del body, ne ritorna la stringa in base64. Questo valore lo mettiamo nell'header come alla riga 120. è corretto?

Per capire, voi prendete il body (il file json) che è presente nella request, ne fate l'hash e lo confrontate con quello della riga 120?

[afrontera85]

calcolando il digest in base al payload inviato mi risulta essere questo (differente da quello inviato): MnQC1V0ad6TwPtw5mx1/9qpb/Q2m4P7LNYIU2QdqO3Y= Non faccio solo l'hash, faccio l'hash e poi lo codifico in base64

[sommafa]

esatto, faccio la stessa cosa io in .Netcore

public static string GetEncodedBody(string jsonInputString)
{
    // Calcola l'hash SHA-256 del contenuto JSON
    byte[] hash;
    using (SHA256 sha256 = SHA256.Create())
    {
        hash = sha256.ComputeHash(Encoding.UTF8.GetBytes(jsonInputString));
    }

    // Codifica l'hash in Base64
    return Convert.ToBase64String(hash);
}

Il codice mi sembra faccia esattamente la medesima cosa del vostro client in java, non vedo particolari differenze.

questo è il file di input

{
  "idOperazioneClient": "1as4qjlkjl434lklk",

  "criteriRicerca": {
    "codiceFiscale": "QRTSGT90A01H501B"
  },
  "datiRichiesta": {
    "dataRiferimentoRichiesta": "2024-02-08",
    "motivoRichiesta": "1",
    "casoUso": "C019"
  }
}

Quindi tu mi confermi che l'errore stia li, nel fatto che ti mando un input del quale però ti mando il Digest diverso nell'http header? o potrebbe nascondere altro?

grazie

[sommafa]

adesso ho fatto una prova e ho schiantato da codice il digest così come me lo hai passato tu, e ora ottengo ancora errore 400 con govway 352526d4-cc24-11ee-a833-005056ae1884

Mi sai dire che altri errori ci possono essere?

grazie

[afrontera85]

Ora l'errore è questo: Verifica ModI della richiesta fallita: Riscontrate 2 eccezioni. Token scaduto in data '2024-02-15_18:06:54.000' [Header 'Agid-JWT-TrackingEvidence'] Token scaduto in data '2024-02-15_18:06:51.000'

[sommafa]

con questo govway 2e34ff8f-cc27-11ee-8a6d-005056ae5232 che errore hai? ho verificato e i token scadono 15/02/2024 18:38:02

grazie

[afrontera85]

Verifica ModI della richiesta fallita: Riscontrate 3 eccezioni. Token creato nel futuro (data creazione: '2024-02-15_19:28:07.000') [Header 'Agid-JWT-TrackingEvidence'] Token non utilizzabile prima della data '2024-02-15_19:28:01.000' [Header 'Agid-JWT-TrackingEvidence'] Token creato nel futuro (data creazione: '2024-02-15_19:28:01.000')

[sommafa]

Ora funziona!

devo capire cosa ci sia di sbagliato nel modo in cui calcolo il digest però.. hai qualche indicazione da darmi? qualcosa di cui tenere conto e che posso essermi perso?

grazie davvero del supporto finora Fabio

[afrontera85]

non so... il client java che abbiamo fornito è funzionante, in teoria se il tuo è uguale dovrebbe funzionare, però se non ricordo male qualcuno in un'altra issue aveva avuto problemi col suo client .net

[sommafa]

Il codice sembra la conversione in .net più simile al vostro codice Java. Ma sicuramente qualche differenza c’è visto il risultato.

ti viene in mente qualche altro elemento delle issue di altri con problemi in .net che possa usare per fare una ricerca?

grazie

[sommafa]

@afrontera85 stamattina ho risolto con successo il problema. sbagliavo io a passare la stringa.

grazie ancora del supporto Fabio

[afrontera85]

@afrontera85 stamattina ho risolto con successo il problema. sbagliavo io a passare la stringa.

grazie ancora del supporto Fabio

perfetto, di nulla