Open fmartelli opened 2 years ago
Giocando un po' col codice confermo quanto detto sopra: almeno per il test 111, nel metodo check_response in response.py viene verificato res.status_code in attendeds. Nel caso in esame lo status code è 200 mentre gli attendeds sono [400, 401, 403, 422, 500]. Per questo motivo il test fallisce.
Tuttavia questo comportamento è in contraddizione con quanto riportato all'indirizzo seguente https://github.com/italia/spid-regole-tecniche/blob/002bf87a6f7f89b84349fcadfe59d29aff30b98e/messaggi-errore.rst per il codice d'errore 25.
Con quale strumento è possibile verificare correttamente il comportamento di un SP? E' questa una anomalia da correggere?
in spid-sp-test i codici di errore attesi sono qui https://github.com/italia/spid-sp-test/blob/main/src/spid_sp_test/responses/settings.py#L1001
in spid-regole-tecniche non vedo codici in contraddizione
spid-sp-test è utilizzato da spid-saml-check per check su metadata e authn request, per le response entrambi adottano le medesime specifiche, pertanto questi sono i tool da utilizzare per testare il comportamento di un SP.
Se avviene un errore è formalmente scorretto rispondere con HTTP 200, non so se e quando la AgID aggiornerà le specifiche di SPID QaD test.
Così su due piedi non correggerei spid-sp-test ma adeguerei il comportamento del SP per adottare un codice di errore HTTP. Vedi questo comportamento come una anomalia?
Buongiorno Giuseppe e grazie per il riscontro.
Il dubbio nasce dal fatto che le specifiche NON parlano di codici HTTP specifici nel caso in esame mentre per altri casi sì. Si potrebbe interpretare la cosa come una libertà nello scegliere con che HTTP Status Code fornire la pagina di cortesia ... Tuttavia il tool di verifica in oggetto si aspetta un codice d'erore tra quelli previsti. Per questo ho immaginato che potesse trattarsi di un baco.
Rivedere il comportamento nel mio SP non è proprio banale quindi, prima di procedere, vorrei essere certo del fatto che la direzione da prendere è quella in linea con l'attuale comportamento di spid-sp-test.
Posso prendere quel che mi dici come un requisito ufficiale? Grazie anticipatamente per l'attenzione.
Risolto forzando il SP a restituire uno tato d'errore in caso di anomalie
Ciao @fmartelli
credo che questa issue sia bene mantenerla aperta fino a quando le specifiche AgID non verranno aggiornate/integrate con questo dettaglio sui codici di errore HTTP. In assenza di questi diventa ferraginoso automatizzare i test.
Questo non significa che i criteri di accessibilità non debbano essere verificati "umanamente" ma credo che sia importante poter automatizzare quanto più possibile con il minore sforzo possibile, se tutti gli automatici vanno bene sarà poi uno sforzo relativamente piccolo quello di verificare le pagine di atterraggio secondo le linee guida di accessibilità. Insomma, si farebbe con un semplice colpo d'occhio
Mi sono "scontrato" anch'io con Giuseppe su questa cosa in passato :-)
Di fatto le specifiche SPID non dicono che il server web debba restituire un HTTP Status Code d'errore quando una pagina d'errore viene mostrata all'utente ed è prassi comune, per pagine che debbano essere fruite da esseri umani, che si usi lo status code 200 indipendentemente dal contenuto semantico della pagina mostrata all'utente (penso, ad esempio, ad una pagina di risposta ad una form di login che ti dice che hai sbagliato le credenziali... dubito fortemente che quella pagina venga restituita con uno status code 401 se non si usa la Basic Authentication ;-)) . Ciononostante, è chiaramente comprensibile come un tool come spid-sp-test non possa fare analisi semantiche sulla pagina mostrata all'utente e solo mediante un opportuno status code HTTP riesca a distinguere una pagina d'errore da una pagina "tutto ok". Onestamente dubito che le specifiche SPID obbligheranno mai le implementazioni a restituire degli status code HTTP d'errore in questi casi, sarebbe un'ulteriore incombenza sostanzialmente inutile (o comunque poco utile) ai fini di una corretta implementazione del workflow a degli utenti umani. Ciò non toglie che utilizzare opportuni status code HTTP in questi casi rimanga una buona prassi e consenta a tool come spid-sp-test di automatizzare una serie di test sulla response che altrimenti bisognerebbe fare "a mano" (come credo spid-saml-check richieda ancora, se non vado errato).
Pertanto @fmartelli, se i controlli di spid-sp-test passano ora che hai aggiunto un opportuno status code HTTP alle tue response d'errore, vai tranquillo che il tuo SP è conforme a quanto richiesto per l'onboarding SPID (salvo che ti contestino elementi grafici o cose di questo tipo).
Buongiorno, mi risulta che vengano segnalati errori sebbene il SP sembra rispettare le specifiche. Un esempio fra tutti è il test 111.
Sebbene alla richiesta annullata dall'utente (segnalata correttamente con errore n25) il SP mostri una pagina di cortesia con indicazione dell'errore ricevuto dall'IdP, il test fallisce ugualmente.
Dando uno sguardo al codice sembrerebbe che spid-sp-test si stia aspetando un HTTP error code, cosa che non è richiesta dalle specifiche.
Nel caso in esame (test 111) sarebbe possibile capire cosa ci si aspetta esattamente e se questo è in linea con quanto richiesto dalle specifiche?