Disconnessione dall'account
Quando un utente esce da un sito web, comunica il suo desiderio di usufruire completamente di un'esperienza utente personalizzata. Per questo motivo è importante rispettare il più possibile il modello mentale dell'utente. Ad esempio, un'esperienza di uscita corretta dovrebbe tenere conto anche delle schede che l'utente potrebbe aver aperto prima di decidere di uscire.
Il segreto di un'ottima esperienza di disconnessione può essere riassunto nella coerenza degli aspetti visivi e dello stato dell'esperienza utente. Questa guida fornisce consigli concreti sugli aspetti a cui prestare attenzione e su come ottenere una buona esperienza di uscita.
Considerazioni principali
Quando implementi la funzionalità di uscita sul tuo sito web, presta attenzione ai seguenti aspetti per garantire una procedura di uscita semplice, sicura e intuitiva:
- Esperienza utente di uscita chiara e coerente: fornisci un pulsante o un link di uscita chiaro e coerente, facilmente identificabile e accessibile in tutto il sito web. Evita di utilizzare etichette ambigue o di nascondere la funzionalità di uscita in menu, pagine secondarie o altre posizioni poco intuitive.
- Richiesta di conferma: implementa una richiesta di conferma prima di finalizzare la procedura di disconnessione. Ciò può aiutare a impedire agli utenti di uscire accidentalmente e consente agli utenti di riconsiderare se hanno davvero bisogno di uscire, ad esempio se bloccano diligentemente il dispositivo con una password efficace o un altro meccanismo di autenticazione.
- Gestisci più schede: se un utente ha aperto più pagine dello stesso sito web in schede diverse, assicurati che la disconnessione da una scheda aggiorni anche tutte le altre schede aperte di quel sito web.
- Reindirizzamento a una pagina di destinazione sicura: una volta uscito, reindirizza l'utente a una pagina di destinazione sicura che indichi chiaramente che non ha più eseguito l'accesso. Evita di reindirizzare gli utenti a pagine contenenti informazioni personalizzate. Allo stesso modo, assicurati che anche le altre schede non riflettano più lo stato di accesso. Inoltre, assicurati di non creare un reindirizzamento aperto che gli utenti malintenzionati possono sfruttare.
- Pulizia della sessione: dopo che un utente si è disconnesso, rimuovi completamente tutti i dati sensibili della sessione, i cookie o i file temporanei associati alla sessione. In questo modo si impedisce l'accesso non autorizzato alle informazioni degli utenti o alle attività dell'account, oltre a impedire al browser di ripristinare le pagine con informazioni sensibili dalle sue varie cache, in particolare la cache back/forward.
- Gestione degli errori e feedback: fornisci agli utenti messaggi di errore o feedback in caso di problemi quando escono. Informarli di eventuali rischi per la sicurezza o fughe di dati se il processo di uscita non va a buon fine.
- Considerazioni sull'accessibilità: assicurati che il meccanismo di disconnessione sia accessibile agli utenti con disabilità, inclusi coloro che utilizzano tecnologie per la disabilità come screen reader o la navigazione da tastiera.
- Compatibilità tra browser: testa la funzionalità di disconnessione su diversi browser e dispositivi per assicurarti che funzioni in modo coerente e affidabile.
- Monitoraggio e aggiornamenti continui: monitora regolarmente il processo di disconnessione per individuare potenziali vulnerabilità o falle per la sicurezza. Implementa patch e aggiornamenti tempestivi per risolvere eventuali problemi identificati.
- Federazione delle identità: se l'utente ha eseguito l'accesso utilizzando un'identità federata, verifica se anche la disconnessione dal provider di identità è supportata e necessaria. Inoltre, se il provider di identità supporta l'accesso automatico, non dimenticare di impedire.
Azioni consigliate
- Se invalidi un cookie sul server nell'ambito di un flusso di disconnessione (o di altri flussi di revoca dell'accesso), assicurati di eliminare il cookie anche sul dispositivo dell'utente.
- Pulisci tutti i dati sensibili che potresti aver archiviato sul dispositivo dell'utente: cookie, localStorage, sessionStorage, indexedDB, CacheStorage e tutti gli altri datastore locali.
- Assicurati che tutte le risorse contenenti dati sensibili, in particolare i documenti HTML, vengano restituite con l'intestazione HTTP
Cache-control: no-store
, in modo che il browser non le archivi nello spazio di archiviazione permanente (ad esempio, su disco). Analogamente, le chiamate XHRs/fetch
che restituiscono dati sensibili devono impostare anche l'intestazione HTTPCache-Control: no-store
per evitare qualsiasi memorizzazione nella cache. - Assicurati che tutte le schede aperte sul dispositivo dell'utente siano aggiornate con le revoche dell'accesso lato server.
Pulizia dei dati sensibili all'uscita
Dopo la disconnessione, valuta la possibilità di cancellare i dati sensibili temporanei e memorizzati localmente. L'attenzione ai dati sensibili è motivata dal fatto che cancellare tutti i dati comporterebbe un'esperienza utente notevolmente peggiore, in quanto questo utente potrebbe tornare. Ad esempio, se cancellassi tutti i dati memorizzati localmente, i tuoi utenti dovranno poi accettare le richieste di consenso all'uso dei cookie e seguire altre procedure come se non avessero mai visitato il tuo sito web.
Come pulire i cookie
Nella risposta della pagina che conferma lo stato di disconnessione, allega le intestazioni HTTP Set-Cookie
per cancellare ogni cookie correlato o contenente dati sensibili. Imposta il valore expires
su una data nel passato e imposta il valore del cookie su una stringa vuota per buona misura.
Set-Cookie: sensitivecookie1=; expires=Thu, 01 Jan 1970 00:00:00 GMT; secure
Set-Cookie: sensitivecookie2=; expires=Thu, 01 Jan 1970 00:00:00 GMT; secure
...
Scenario offline
Sebbene l'approccio descritto sopra sia sufficiente per casi d'uso generici, non funziona se l'utente lavora offline. Prendi in considerazione la possibilità di richiedere due cookie per monitorare lo stato di accesso: un cookie solo HTTPS sicuro e un cookie normale accessibile tramite JavaScript. Se l'utente sta cercando di uscire mentre è offline, puoi cancellare il cookie JavaScript e procedere con altre operazioni di pulizia, se possibile. Se hai un service worker, potresti sfruttare l'API Background Fetch per ritentare una richiesta di cancellazione dello stato sul server quando l'utente sarà online in un secondo momento.
Come liberare spazio di archiviazione
Nella risposta della pagina che conferma lo stato di disconnessione, assicurati di ripulire i dati sensibili dai vari datastore:
sessionStorage: anche se questo campo viene cancellato quando l'utente termina la sessione sul tuo sito web, ti consigliamo di eliminare in modo proattivo i dati sensibili quando l'utente esce dall'account, nel caso in cui dimenticasse di chiudere tutte le schede aperte sul sito web.
// Remove sensitive data from sessionStorage sessionStorage.removeItem('sensitiveSessionData1'); // ... // Or if everything in sessionStorage is sensitive, clear it all sessionStorage.clear();
API localStorage, indexedDB, Cache/Service Worker: quando l'utente si disconnette, ripulisci tutti i dati sensibili che potresti aver archiviato utilizzando queste API, poiché tali dati rimarranno da una sessione all'altra.
// Remove sensitive data from localStorage: localStorage.removeItem('sensitiveData1'); // ... // Or if everything in localStorage is sensitive, clear it all: localStorage.clear();
// Delete sensitive object stores in indexedDB: const name = 'exampleDB'; const version = 1; const request = indexedDB.open(name, version); request.onsuccess = (event) => { const db = request.result; db.deleteObjectStore('sensitiveStore1'); db.deleteObjectStore('sensitiveStore2'); // ... db.close(); }
// Delete sensitive resources stored via the Cache API: caches.open('cacheV1').then((cache) => { await cache.delete("/personal/profile.png"); // ... } // Or better yet, clear a cache bucket that contains sensitive resources: caches.delete('personalizedV1');
Come liberare le cache
- Cache HTTP: se imposti
Cache-control: no-store
su risorse con dati sensibili, la cache HTTP non conserva i dati sensibili. - Cache back/forward: allo stesso modo, se hai seguito i consigli su
Cache-control: no-store
e sulla cancellazione dei cookie sensibili (ad esempio, cookie sicuri solo HTTPS legati all'autenticazione) quando gli utenti si disconnettono, non devi preoccuparti che i dati sensibili vengano conservati nella cache back-forward. In effetti, la funzionalità di cache back-forward rimuove le pagine della stessa origine pubblicate con un'intestazione HTTPCache-control: no-store
se osserva uno o più dei seguenti indicatori:- Uno o più cookie solo HTTPS sicuri sono stati modificati o eliminati.
- Una o più risposte per le chiamate XHR/
fetch
, emesse dalla pagina, includevano l'intestazione HTTPCache-control: no-store
.
Esperienza utente coerente in tutte le schede
Gli utenti potrebbero aver aperto molte schede del tuo sito web prima di decidere di uscire. A quel punto potrebbero dimenticarsi di altre schede o persino di altre finestre del browser. È meglio evitare di fare affidamento sugli utenti per chiudere tutte le schede e le finestre pertinenti. Adotta invece un approccio proattivo assicurandoti che lo stato di accesso dell'utente sia coerente in tutte le schede.
Istruzioni
Per ottenere uno stato di accesso coerente in tutte le schede, puoi utilizzare una combinazione di eventi pageshow
/pagehide
e l'API Broadcast Channel.
Evento
pageshow
: dopo unpageshow
persistente, controlla lo stato di accesso dell'utente ed elimina i dati sensibili (o l'intera pagina) se l'utente non ha più eseguito l'accesso. Tieni presente che l'eventopageshow
viene attivato prima che la pagina venga visualizzata per la prima volta dopo essere stata ripristinata da una navigazione back-forward, garantendo che il controllo dello stato dell'accesso ti consenta di reimpostare la pagina a uno stato non sensibile.window.addEventListener('pageshow', (event) => { if (event.persisted && !document.cookie.match(/my-cookie)) { // The user has logged out. // Force a reload, or otherwise clear sensitive information right away. body.innerHTML = ''; location.reload(); } });
API Broadcast Channel: utilizza questa API per comunicare le modifiche allo stato dell'accesso nelle schede e nelle finestre. Se l'utente non ha eseguito l'accesso, cancella tutti i dati sensibili o, in alternativa, reindirizza a una pagina di uscita in tutte le schede e le finestre con dati sensibili.
// Upon logout, broadcast new login state so that other tabs can clean up too: const bc = new BroadcastChannel('login-state'); bc.postMessage('logged out'); // [...] const bc = new BroadcastChannel('login-state'); bc.onMessage = (msgevt) => { if (msgevt.data === 'logged out') { // Clean up, reload or navigate to the sign-out page. // ... } }
Conclusione
Seguendo le indicazioni fornite in questo documento, sarai in grado di progettare un'ottima esperienza utente che si disconnetta, in modo da evitare disconnessioni involontarie e proteggere le informazioni personali dell'utente.