Timeout della sessione

Comprendo il tuo ragionamento, Stephen, ma non è allarmistico.

Gli addetti all’IT affrontano ogni giorno utenti inconsapevoli e/o cosiddetti “incompetenti”. Cerchiamo di implementare sistemi in grado di gestire ogni evenienza, e non è affatto facile. L’identità è un tema cruciale oggi, ed è stato solo tramite i test che abbiamo scoperto questo problema: un preavviso sarebbe stato gradito, soprattutto considerando che la questione è stata discussa (e risolta una volta) già dal 2016.

Il mio auspicio era di aver trascurato qualcosa o di aver trovato una configurazione errata, ma ora so che il sistema funziona come previsto. Valuteremo soluzioni esterne per aggirare il problema, le documenteremo per i nostri utenti e, speriamo, in futuro altri faranno pressione affinché questo problema venga risolto all’interno di Discourse.

Ma cosa succede se l’utente dimentica di chiudere il browser? Come funziona?

Tuttavia, sono curioso, @falco: perché la patch del 2016 è stata annullata? È una modifica non sicura?

Alcuni punti validi.

Tuttavia, sono piuttosto scioccato da alcuni dei tuoi esempi:

Ospedali: quelli in cui sono stato negli ultimi anni hanno senz’altro dei blocchi di sessione unici, al punto che l’infermiere che esegue le analisi del sangue deve effettuare nuovamente il login dopo essersi allontanato per pochi secondi.

Nel pronto soccorso, potrebbero esserci alcuni sistemi specializzati con accesso a dati rilevanti per le emergenze, ma non dovrebbero avere accesso a informazioni personali identificabili (PII) o al forum di chat del dipartimento.

Biblioteche:
Tutte le biblioteche pubbliche locali (inclusi alcuni paesi molto piccoli con personale poco esperto di tecnologia) hanno un ID di accesso generico (uguale per tutti gli utenti, esposto direttamente sul monitor). Hanno anche una politica di riavvio automatico all’abbandono della postazione, e tutti, inclusi i bambini, sono tenuti a rispettarla. La sequenza di riavvio include la cancellazione automatica della cronologia, della cache e dei cookie del browser.

Non sto dicendo che una politica più attenta sul lato della discussione non sia una buona cosa; è solo che alcune delle situazioni “scatenanti” elencate in questo argomento mi preoccupano, perché i post del forum attribuiti erroneamente sono il minimo dei loro problemi.

1 Mi Piace

La cronologia è la seguente:

  • 2012 - maggio 2016: il cookie di sessione di Discourse è sempre impostato su “per sempre”

  • Maggio 2016 - luglio 2016: il cookie di sessione di Discourse è impostato su “per sempre” come predefinito; un’impostazione del sito può farlo scadere alla chiusura del browser.

  • Luglio 2016 - oggi: il cookie di sessione di Discourse è impostato su 1440 ore e si rinnova con l’uso. Un’impostazione del sito può controllare la durata massima. L’impostazione del cookie di sessione del browser è stata rimossa.

È stato rimosso principalmente perché

Posso capire che condividere computer con estranei sia un concetto molto estraneo in alcune parti del mondo, ancor di più con i dispositivi personali mobili e ora con la COVID-19, ma è davvero comune in alcuni luoghi come biblioteche scolastiche, luoghi di lavoro, ecc.

Nella maggior parte dei casi, ciò che fanno è spegnere il computer dopo averlo utilizzato. Spegnere il computer chiuderà il browser, quindi spegnere un computer interromperà indirettamente la sessione di accesso nelle applicazioni web.

Quando il prossimo dipendente arriva per il turno successivo, il computer viene riavviato e il browser non conterrà più i cookie basati sulla sessione.

1 Mi Piace

Giusto, ma penso anche che impostare questo valore a qualcosa come 0 dovrebbe eventualmente (se non causa troppi problemi di assistenza o non è troppo difficile dal punto di vista tecnico) comportare il funzionamento del “cookie valido solo per la durata della sessione del browser”. Quindi la descrizione dell’impostazione del sito potrebbe indicare questo.

età massima della sessione [predefinito 1440 ore]

L’utente rimarrà connesso per n ore dall’ultima visita. Se impostato a 0, l’utente verrà disconnesso quando il browser viene chiuso.

3 Mi Piace

Ospedali: Condivido solo ciò che so essere fatto per esperienza. Concordo sul fatto che gli schermi si blocchino rapidamente, ma ciò non equivale a una disconnessione dal browser, figuriamoci dall’utente del sistema operativo. Potete immaginare cosa farebbero le persone se il computer dovesse effettuare l’accesso, applicare le policy, configurare le connessioni di rete, tutto prima di caricare un’applicazione per svolgere qualsiasi attività che medici e infermieri devono compiere mentre qualcuno sta morendo? In modo simile, gli accessi non avvengono solitamente tramite nome utente e password, quanto piuttosto tramite badge più un breve PIN, per la stessa ragione. I pronto soccorso, le sale operatorie e la maggior parte degli altri ambienti devono ancora documentare le informazioni sui pazienti, quindi nei contesti in cui ho lavorato la prassi è stata coerente ovunque.

Biblioteche: Esistono policy di riavvio alla disconnessione che sono efficaci solo se gli amministratori puliscono manualmente le cache di tutto ciò che è presente sulla macchina, ma ho visto altrettanti luoghi fare diversamente (una delle tante ragioni per cui non ho mai utilizzato, e intendo mai, workstation condivise con le mie credenziali). Ho visto la stessa sfortunata configurazione regolarmente anche in hotel e cybercafé (o caffetterie), per quanto possa valere.

Mi sembra strano che qualsiasi applicazione imposti questa configurazione come predefinita per tutti gli utenti in tutte le installazioni. La sicurezza non è l’obiettivo principale della maggior parte delle persone quando configurano per la prima volta i computer, e la complessità è tale che è un lavoro a tempo pieno per gli specialisti. Chi configura computer per il pubblico dovrebbe saperlo meglio, ma i browser hanno il concetto di cookie di sessione per rendere facile agli sviluppatori di applicazioni gestire sessioni quando è intuitivo per gli utenti.

Richiedere agli utenti di comprendere che devono cancellare manualmente i cookie di un sito per disconnettersi, quando molti siti sia scadono la sessione sia la terminano alla chiusura del browser, sembra richiedere troppo alle persone. Non permettere affatto l’alternativa, cosicché un utente deve ricordarsi di utilizzare il link specifico di disconnessione di Discourse, diventa un problema quando gli utenti perdono il link per qualsiasi motivo; a mente:

  • L’utente si sposta da Discourse seguendo un link.
  • L’utente si sposta da Discourse perché usa la scheda per andare altrove esplicitamente.
  • L’utente chiude la scheda in fretta per andare a lezione/riunione/ecc.
  • Il browser si blocca per qualsiasi motivo.
  • L’implementatore SSO ha SAML per l’accesso, ma non sa che l’applicazione richiede una disconnessione esplicita per terminare la sessione dell’applicazione.

Inoltre, due (2) mesi sembrano un tempo VERAMENTE lungo per una persistenza dell’accesso. So che alcuni altri siti oggi potrebbero farlo, o anche di più, ma gli utenti possono solitamente controllarlo con quelle caselle “Computer pubblico”, che non si applicano con SSO, o forse non esistono affatto (non sono un guru di Discourse).

Solo ulteriori riflessioni da considerare.

Anch’io ho questo problema e non so come risolverlo.

Grazie per questo, @codinghorror. Qual è il processo e i tempi per valutarlo e implementarlo?

Non lo so, dipende da quanto sia tecnicamente complessa la modifica. @sam, cosa ne pensi della difficoltà di quanto proposto nel mio post precedente?

Penso che questa sarebbe una funzione interessante, perché permetterebbe di sapere chi è effettivamente online e chi è solo assente.

Abbiamo davvero bisogno di una nuova impostazione del sito qui, perché questo è concettualmente disaccoppiato e renderebbe il codice difficile da comprendere.

In particolare, dovremmo aggiungere dei minimi qui:

e in alcune altre posizioni per garantire che il codice continui a funzionare.

L’impostazione che vogliamo è una discreta opzione del tipo “disconnetti automaticamente gli utenti quando il browser viene chiuso”.

La durata della sessione si applica comunque anche se si utilizzano i cookie di sessione (ovvero si omette expires).

Quindi, ad esempio, potresti dire:

  1. Se gli utenti chiudono il laptop e lo riaprono dopo 3 ore, vuoi che siano disconnessi.
  2. Se gli utenti chiudono Chrome, vuoi che siano disconnessi.

Sono preoccupazioni diverse.

Forse aggiungiamo persistent_sessions con valore predefinito true? “quando impostato su true, la sessione viene mantenuta quando il browser viene chiuso”. Questa modifica richiede circa 20 minuti.

4 Mi Piace

Ok, se una impostazione separata del sito è migliore e si tratta di una modifica semplice da 20 minuti, allora dico: facciamolo.

2 Mi Piace

Forse in futuro questa buona idea potrà essere estesa a un’impostazione “per utente” invece che solo “per sito”?

1 Mi Piace

Questo è ora gestito come impostazione per sito.

https://review.discourse.org/t/feature-add-support-for-not-persistent-sessions/15171

Sembra davvero una scelta amministrativa. Si tratta di una funzionalità di sicurezza. A lungo termine, potremmo valutare una lista bianca di indirizzi IP che escludono dal limite (ad esempio, i computer nella rete aziendale rimangono connessi, mentre quelli esterni vengono disconnessi automaticamente).

4 Mi Piace

Credo che, per la natura di questa richiesta, si tratti di una funzionalità per utente.

Alcuni utenti utilizzano i propri computer a casa o in ufficio e non hanno bisogno che i cookie scadano; quindi dovrebbe essere una loro scelta.

Altri utenti potrebbero essere quei “nomadi” nei caffè che usano computer condivisi e vorrebbero che le loro sessioni scadessero.

La natura di questa funzionalità riguarda la sicurezza dell’account utente, pertanto questa impostazione è stata solitamente implementata come opzione o casella di controllo per l’utente al momento dell’accesso.

vBulletin, ad esempio, aveva questa funzionalità OOTB oltre un decennio fa e, quando accedevamo, selezionavamo semplicemente una casella se “noi, l’utente”, volevamo che la nostra sessione persistesse.

La “sicurezza” riguarda gli account utente, quindi in passato si è trattato solitamente di un’impostazione per utente, a titolo informativo.

Aggiornamento: Quando l’utente ha un account privilegiato (amministratore, moderatore, leader, ecc.), sorge anche il problema più ampio della sicurezza complessiva del sito.

2 Mi Piace

L’ho vista implementata su moltissimi siti; l’implementazione tipica è:

Mantienimi collegato per 30 giorni

[ ACCEDI ]

Non sono sicuro di quando arriveremo a questo punto, ma quando lo faremo, probabilmente richiederemo un’impostazione del sito per abilitarla. Ci sono complicazioni riguardo a dove mostrare una casella di controllo del genere se hai abilitato l’accesso tramite social.

5 Mi Piace

Grazie a tutti, la vostra collaborazione e comprensione sono molto apprezzate

1 Mi Piace

Grazie.

Sì, l’accesso tramite social non è mai stato “il nostro punto di forza” a causa del tracciamento del comportamento; quindi la mia prospettiva è molto più ristretta rispetto alla tua esigenza molto più ampia e complessa di supportare i social.

Grazie per il buon lavoro di tutto il tuo team. Ottimo lavoro.

4 Mi Piace

Prima di tutto: grazie mille per la correzione rapida. Ho però una domanda: sarebbe possibile trasformarlo in un’impostazione per utente con un valore predefinito specifico, in modo che gli utenti possano disattivarlo dalle proprie preferenze?

1 Mi Piace

È esattamente ciò che è stato discusso sopra come possibile lavoro futuro, poiché entrambe le opzioni richiedono più impegno e presentano alcuni spiacevoli problemi di design dell’interfaccia utente.

Inoltre, vogliamo rendere la funzionalità disponibile per un po’ di tempo per vedere se qualcuno riscontra problemi tecnici con il nostro approccio.

3 Mi Piace