Dovrai tenere traccia del lato server dello stato sessione per questo, e scadere le sessioni che non hanno avuto alcuna attività entro l'ultimo X numero di secondi. Supponiamo che X sia 60 , il che significa che forzerai il logout in tutte le sessioni che non hanno avuto alcuna attività nell'ultimo minuto.
Se non vuoi che gli utenti siano disconnessi se non navigano verso un'altra pagina entro ogni minuto, potresti avere un keep-alive AJAX che farà una richiesta alla pagina. Suggerirei di utilizzare X/2 secondi per questo controllo per consentire la latenza della rete temporale. Quindi ogni 30 secondi di attivazione di AJAX, inviando il cookie di sessione al server che aggiornerà il tempo di last action registrato rispetto alla sessione con l'ora corrente del server.
È comunque possibile implementare un timer di inattività che scadrà la sessione se si dice che si ricevono 15 minuti di keep-alive AJAX ma nessuna richiesta manuale da parte dell'utente.
Alla fine della giornata, è necessario rendersi conto che questa è una situazione controllata dal cliente in modo da poterlo fare solo così lontano. Ad esempio, un utente può aggiornare automaticamente la pagina utilizzando un plug-in del browser per impedire il logout automatico.
some browsers suspending JavaScript code for backgrounded tabs (or applications on mobile).
Se questo è un problema, puoi aumentare il valore di X . Se l'applicazione è altamente sensibile, forse l'educazione degli utenti è la chiave. Insegna ai tuoi utenti che devono disconnettersi quando hanno finito di usare la tua applicazione. È possibile rilevare se gli utenti stanno scadendo o si disconnettono esplicitamente, e se è più spesso il primo è possibile visualizzare un messaggio importante sul proprio sito.
What are the highest-security websites currently doing in this space?
Esiste un modo molto sicuro, tuttavia questo dovrebbe essere implementato da zero all'interno della tua architettura di applicazioni web e non può essere semplicemente inserito. Qui gli ID di sessione sono collocati in campi di moduli nascosti invece di essere contenuti in un biscotto. Tuttavia, devono essere inviati da POST (vale a dire nel corpo della richiesta). L'utilizzo di questo in combinazione con il caching disabilitato impedirà il proseguimento di una sessione tra i riavvii del browser.
Lo svantaggio di questo approccio è che è necessaria un'azione di navigazione ogni per inviare un modulo.
Ad esempio potremmo avere un modulo per gestire la navigazione su ogni pagina costruita in questo modo:
<form method="post" action="/navigate">
<input type="hidden" name="navigationPage" />
<input type="hidden" name="sessionId" value="12345678" />
</form>
Con un clic all'interno della navigazione JavaScript verrà eseguito e impostato navigationPage sul valore appropriato (ad esempio myAccount , orderHistory , ecc.) e quindi inviare il modulo. L'URI /navigate verificherà sessionId e quindi passerà alla pagina specificata in navigationPage se la sessione è valida. Usando questo metodo ogni pagina all'interno della sessione di accesso avrà lo stesso URI ( www.example.com/navigate in questo caso).
Questo è più sicuro dell'aggiunta di un valore di stringa di query in quanto l'ID di sessione non sarà trapelato in referer di intestazioni nel caso di link esterni. I collegamenti esterni possono semplicemente collegarsi direttamente alla risorsa e non saranno il modulo POST utilizzato dalla navigazione interna.
Molti sistemi bancari utilizzano una tecnica simile per una protezione extra contro il dirottamento di sessione all'interno della sessione. In questi scenari, sessionId nel campo modulo nascosto verrà rigenerato su ogni caricamento di pagina che garantisce che solo un singolo browser Web stia navigando contemporaneamente. Tuttavia, ciò impedirà l'utilizzo del pulsante Indietro perché impone una nuova presentazione dei dati POST o l'apertura di collegamenti in schede separate del browser, in quanto l'ID rolling non verrà aggiornato in entrambe le posizioni. Questo è spesso usato in combinazione con i cookie di sessione, ma può essere usato in isolamento. Le azioni che richiedono informazioni aggiuntive come i trasferimenti di denaro possono semplicemente includere campi di moduli aggiuntivi da inviare con il modulo principale.
Un altro vantaggio di questo approccio è che è intrinsecamente sicuro contro CSRF . Se un'altra pagina effettua una richiesta cross site, mancherà il sessionId perché non verrà inviata automaticamente allo stesso modo dei cookie.
Questo può anche essere implementato in HTML solo senza JavaScript, dove ogni pulsante sulla pagina invierà un ID di navigationPage .
Questo approccio significa che puoi anche mantenere il timeout della sessione corrente e non è necessario un battito cardiaco.