Uno delle aree più delicate e più importanti del collaudo di siti web è la sicurezza. Collaudare quest'area è uno degli obiettivi centrali del web tester di SimpleTest.
Se si prova a prelevare una pagina protetta con un sistema
di autenticazioen di base, invece di riceverne il contenuto si
ottiene un header 401.
Si può illustrare questo caso con il test seguente:
Una caratteristica di SimpleTest è di permettere l'utilizzo
di oggetti SimpleExpectationladdove un semplice confronto
di pattern non sia sufficiente.
Se si desidera solo un confronto approssimativo delle credenziali
per esempio, si può fare così:
La maggior parte delle volte non si è interessati al collaudo
dell'autenticazione in se', ma la si vuole eseguire per accedere
al collaudo delle pagine sottostanti.
Non appena la richiesta di autenticazione è stato emesso si potrà
restituire una risposta di autenticazione:
Se si vuole, si può accorciare ancor più questo passo codicificando
le credenziali direttamente nell'URL:
If you want, you can shortcut this step further by encoding
the log in details straight into the URL...
Un problema nella codifica delle credenziali di autenticazione direttamente nell'URL è che l'header di autenticazione non viene inviata automaticamente ad ogni successiva richiesta. Se si naviga il sito mediante URL relative, tuttavia, le informazioni di autenticazioni verranno conservate insieme al nome di dominio.
Di solito, però, si utilizza la chiamata a authenticate().
SimpleTest ricorderà allora le credenziali ad ogni richiesta.
Attualmente è supportato solo il collaudo dell'autenticazione di base e questo è da considerarsi sicuro solo se usato insieme ad una connessione HTTPS. Comunque, di solito questo è sufficiente per proteggere il server da occhi indiscreti. La Digest authentication e l'autenticazione NTLM potrebbero venire aggiunte nel futuro se abbastanza persone dovessero richiedere queste feature.
Per gli sviluppatori web l'autenticazione di base non fornisce sufficiente controllo sull'interfaccia utente. Molto più probabilmente questa funzionalità sarà codificata direttamente dentro l'architettura dell'applicazione per mezzo di cookie e di complessi timeout. E' necessario essere in grado di collaudare anche questo.
Iniziamo con un semplice form di login:
Password:
]]>
Supponiamo che recuperando questa pagina venga impostato un
cookie con l'ID di sessione.
Non abbiamo intnzione di riempire il form, ancora: vogliamo solo
verificare che l'utente venga tracciato.
Ecco il test:
Il miglior modo per verificare l'avvenuta autenticazione è
analizzare la pagina successiva per vedere se si è davvero loggati.
E' sufficiente verificare la successiva pagina con WebTestCase::assertText().
Questo testo è simile a qualsiasi altro test di form
ma si vorrà verificare che dopo l'autenticazione si starà
ottenendo lo stesso cookie di quello ottenuto al momento di entrare.
Non si vuole perdere traccia di questo, dopo tutto.
Ecco un possibile test per questo caso:
Potremmo provare perfino a compromettere il nostro stesso
sistema impostanto un cookie arbitrario per tentare di
ottenere l'accesso senza autenticazione:
If you are testing an authentication system a critical piece
of behaviour is what happens when a user logs back in.
We would like to simulate closing and reopening a browser...
WebTestCase::restart() conserva i cookie
non ancora scaduti ma elimina quelli temporanea e quelli scaduti.
Opzionalmente si può indicare la data e l'ora nelle quali far
avvenire il riavvio.
I cookie scaduti possono essrer un problema. Dopo tutto, se si dispone di un cookie che scade dopo un'ora non si potrà sospendere il test per un'ora intera nell'attesa che il cookie scada.
Per portare i cookie oltre il limite dell'ora è possibile
invecchiarli prima di riavviare la sessione: