Errore 404 in richiesta dettagli flusso rendicontazione da console amministrazione

[pperliti]

Descrizione del Bug Autenticandosi da console amministrazione, richiedendo la lista dei flussi e quindi cliccando su un qualunque flusso per visualizzarne i dettagli si ottiene un errore 404. Il problema sembra legato all'URL che accoda all'id flusso anche il timestamp del flusso comprensivo di timezone (es. "+0100"). Rimuovendo la parte di timezone dall'URL, la risposta è quella attesa.

Come riprodurlo: Autenticarsi da console amministrazione, richiedere la lista dei flussi e quindi cliccare su un qualunque flusso per visualizzarne i dettagli.

Risultato atteso: Descrizione del comportamento previsto.

Ambiente:

• GovPay: 3.7.6
• AS: WildFly 26
• Java: Temurin 11

• Note aggiuntive: Ulteriori informazioni utili all'identificazione e risoluzione del problema

[pperliti]

Aggiungo un dettaglio alla precedente segnalazione. Il problema si presenta avendo IIS davanti a GovPay, accedendo direttamente all'istanza di GovPay il problema sembra non esserci (dunque non si tratta di un bug di GovPay).

Accesso tramite IIS: https://<URL_DOMINIO_IIS>/govpay/backend/api/backoffice/rs/form/v1/flussiRendicontazione/<CF_DOMINIO>/<ID_FLUSSO)/YYYY-MM-DDTHH:MM:SS.ZZZ+0100 restituisce 404

https://<URL_DOMINIO_IIS>/govpay/backend/api/backoffice/rs/form/v1/flussiRendicontazione/<CF_DOMINIO>/<ID_FLUSSO)/YYYY-MM-DDTHH:MM:SS.ZZZ restituisce 200

Accesso diretto a WildFly: http://localhost:8080/govpay/backend/api/backoffice/rs/form/v1/flussiRendicontazione/<CF_DOMINIO>/<ID_FLUSSO)/YYYY-MM-DDTHH:MM:SS.ZZZ restituisce 200

[nardil]

Ciao @pperliti, puoi condividere:

• il tipo di database
• il timezone del database
• il timezone della JVM di GovPay
• il dato YYYY-MM-DDTHH:MM:SS.ZZZ nella URL
• il valore della colonna fr.data_ora_flusso su db per quel flusso

Grazie

[pperliti]

• database: SQL Server (su Azure)
• timezone del database: SELECT CURRENT_TIMEZONE() --> (UTC) Coordinated Universal Time e SELECT SYSDATETIMEOFFSET() --> 2024-03-15 08:33:17.624 +0000
• timezone della JVM di GovPay: -Duser.timezone=Europe/Rome"
• dato YYYY-MM-DDTHH:MM:SS.ZZZ nella URL: /flussiRendicontazione/<ID_DOMINIO>/<ID_FLUSSO>/2024-03-15T03:31:07.000+0100
• valore della colonna fr.data_ora_flusso su db per quel flusso: 2024-03-15 03:31:07.000

[nardil]

Non mi torna il dato memorizzato su database: essendo il timezone del DB impostato a UTC, mi sarei aspettato come data_ora il valore 2024-03-15 02:31:07.000

Puoi verificare se gli orari del giornale degli eventi ti risultano corretti o "sfasati" di un'ora?

[pperliti]

Ciao Lorenzo, no gli eventi nel giornale non sono sfasati (né da UI né su DB). Non vorrei che il rewrite di IIS encodasse male l'URL verso WildFly perché bypassando IIS la chiamata a GovPay funziona restituendo il dettaglio del flusso.

[nardil]

Scusa, non mi è chiaro: la stessa URL chiamando direttamente GovPay funziona, mentre passando da IIS no?

[pperliti]

Esatto. Lo fa solo con quell'URL, è davvero strano. Chiudo comunque la segnalazione perché non è un problema legato a GovPay, poi se ne vengo a capo scrivo come ho risolto (non si sa mai che capiti a qualcun altro).

[nardil]

Perfetto, grazie!

[pperliti]

Credo di esserne venuto a capo. Il problema è legato all'URL di richiesta dettaglio flusso, il quale contiene il simbolo "+" per la parte di timezone (es. /flussiRendicontazione/<ID_DOMINIO>/<ID_FLUSSO>/2024-03-15T03:31:07.000+0100). IIS blocca questi URL restituendo un 404.11 ("The request filtering module is configured to deny a request that contains a double escape sequence."). In effetti come documentato in questo post il simbolo (+) è un carattere riservato per RFC2396.

The issue is when a ‘+’ character appears in a URL. The ‘+’ character doesn’t appear to be escaped, since it does not involve a ‘%’. Also, RFC 2396 notes it as a reserved character that can be included in a URL when it’s in escaped form (%2b). But with allowDoubleEscaping set to its default value of false, we will block it even in escaped form. The reason for this is historical: Way back in the early days of HTTP, a ‘+’ character was considered shorthand for a space character. Some canonicalizers, when given a URL that contains a ‘+’ will convert it to a space. For this reason, we consider a ‘+’ to be non-canonical in a URL. I was not able to find any reference to a RFC that calls out this ‘+’ treatment, but there are many references on the web that talk about it as a historical behavior.

Una soluzione è quella di abilitare il double-escaping. Per IIS significa aggiungere questa direttiva nel file web.config:

<security>
   <requestFiltering allowDoubleEscaping="true" />
</security>

Tuttavia potrebbe aprire una potenziale falla nella sicurezza del sistema (consentendo code injection).

Accedendo direttamente a WildFly bypassando IIS il problema non si presenta, ma a dire il vero non capisco se sia una buona notizia.

[nardil]

Corretto: del carattere + va fatto l'URL Encoding e convertito in %2B.

Puoi confermarmi che cosi funziona?

[nardil]

Leggo però nel frammento che "we will block it even in escaped form"...

[pperliti]

Ti confermo che sostituendo il + con %2B si ottiene comunque un 401.11 (dal trace delle richieste vedo che IIS fa il decode di %2B in +).

Confermo anche che abilitando su IIS allowDoubleEscaping="true" tutto funziona (anche senza effettuare encoding), anche se al momento preferisco non farlo.

[nardil]

Uhmmm capisco.... chiudo nuovamente.