Ciao, ho ricevuto segnalazioni secondo cui diversi membri del mio forum vengono disconnessi automaticamente dopo 20-30 minuti.
Utilizzo l’SSO, quindi mi chiedo se il problema possa essere legato al fatto che gli utenti accedono al sito principale, poi entrano in Discourse (che avvia una nuova sessione lì?), tornano al sito principale (rendendo Discourse inattivo) e infine rientrano in Discourse, venendo in qualche modo disconnessi.
(Tuttavia, questo non ha molto senso, perché ogni volta che entrano in Discourse, il “timeout di inattività” dovrebbe essere resettato a 0, giusto?)
Ho trovato alcune discussioni sui timeout e simili qui in meta, ma nessuna sembra offrire una risposta chiara.
Domanda: esiste un’impostazione per impedire che i membri vengano disconnessi finché non sono inattivi per un periodo X? Non riesco a trovarla.
Nei miei impostazioni di Discourse vedo che ho impostato la “durata massima della sessione” a 1 ora, ma non credo che ciò faccia molta differenza con un’implementazione SSO, vero? (Nota: quando un membro si disconnette dal mio sito principale, invio un messaggio /logout a Discourse, solo per mantenere tutto ordinato. E ogni volta che un membro compie qualsiasi attività in Discourse, aggiorno l’orario dell’ultima attività sul mio sito principale, quindi non è il sito principale a scattare il timeout. Sto aggiungendo codice di debug aggiuntivo per confermare che tutto funzioni come dovrebbe.)
Si applica anche all’SSO, quindi è probabile che sia la causa del tuo problema. Dopo 1 ora di inattività, la sessione Discourse verrà terminata e gli utenti dovranno autenticarsi nuovamente tramite SSO.
Va bene, ed è assolutamente corretto… dopo 1 ora di inattività, dovrebbero essere disconnessi.
Il problema è che ricevo segnalazioni di persone disconnesse dopo 20-30 minuti.
C’è un’impostazione per quel timeout di inattività di 1 ora? Come ho menzionato nel mio post originale, non riesco a trovarlo… e mi sembra il primo posto dove controllare, no?
Solo per escludere la causa più ovvia… è possibile che le persone abbiano sbagliato l’orario esatto? 30 minuti e un’ora non sono poi così diversi
Per continuare il debug, suggerirei che il prossimo passo sia esaminare i dati disponibili nelle tabelle user_auth_tokens e user_auth_token_logs. Contengono tutte le informazioni sui token di sessione e sulla scadenza.
Mmh. Mentre gli utenti utilizzano i forum e leggono gli argomenti, ecc., se compiono un’azione che genera un evento (create_post, create_topic, edit_post, ecc.), ricevo un messaggio tramite webhook. Questo informa il sito principale che sono ancora attivi, permettendomi di aggiornare il valore ‘Ultimo click’ nella loro sessione ed evitare il logout. Come dovrebbe essere. Tutto a posto.
Tuttavia, se un membro si limita a leggere i messaggi per un po’… il tempo di inattività su Discourse viene resettato ogni volta che compie un’azione (il che è positivo), ma il mio sito principale non riceve alcun messaggio webhook che indichi che l’utente è attivo. Quindi, dopo un’ora senza alcuna attività (sembra che siano andati sul forum e si siano allontanati dal computer), il sito principale presume che siano fuori gioco e li disconnette.
Sembra esserci un buco nella logica. Per un’implementazione SSO corretta, non dovrebbe esserci un modo per cui Discourse mi informi se la sessione di un utente è attiva (anche se stanno solo leggendo)? Forse Discourse dovrebbe inviare un ping ogni 5 minuti se il membro è attivo ma non ha generato altri messaggi webhook.
Oppure, quando il mio sito pensa che un utente sia scaduto, dovrei chiamare Discourse e chiedere se l’utente è attivo lì. Esiste un modo per farlo? (Vedo Is there an endpoint to check if a user is logged in - #3 by pfaffman ma non riesco a capire bene se sia quello che mi serve, e /session/current.json non è documentato nell’API.) Questo genererebbe un’enorme quantità di chiamate API: sul mio sito disconnetto circa 15-20 utenti al minuto per inattività, quindi dovrei chiamare per ciascuno (e forse più di una chiamata, se non ho una cache locale del loro ID Discourse).
Ogni endpoint del profilo ha un valore last_seen, che potresti utilizzare.
Non credo di aver mai visto questo tipo di configurazione in nessun protocollo SSO, e non abbiamo ricevuto richieste di questo genere. Più comunemente, le persone mantengono i due sistemi indipendenti.
Se volessi davvero creare un webhook per ‘utente visto’, potresti riuscirci utilizzando un plugin personalizzato.
Non sono sicuro di cosa intendiate per “mantenere i due sistemi indipendenti”? Fatemi sapere se mi sto perdendo qualche soluzione ovvia al problema che ho esposto, per favore!
Altrimenti, sembra che le mie opzioni siano:
Quando un utente scade sul sito principale, prima di disconnetterlo, chiamare Discourse e controllare il valore last_seen per vedere se il membro è stato effettivamente attivo nei forum (anche se non sta facendo nulla che generi una chiamata webhook). Vantaggi: facile da fare. Svantaggi: genererà molte chiamate API, che è già una cosa con cui sto lottando e devo aggirare i limiti di velocità.
Creare il mio plugin per fare il ping al mio sito principale ogni tanto, così da poter aggiornare l’ultima attività dell’utente sul mio sito principale. Vantaggi: sembra più la soluzione “giusta” (per indicare l’attività con un messaggio push); in qualche modo elegante. Svantaggi: non facile da implementare.
Cambiare il tempo di logout sul mio sito principale a 2 ore. Vantaggi: facile da implementare. Svantaggi: ce ne sono?
Non preoccuparsene. Gli utenti vengono disconnessi nel mezzo della loro sessione su Discourse e si lamentano terribilmente. È quello che ho ora. Vantaggi: facile da implementare, lol. Svantaggi: un’esperienza utente molto scarsa.
Ho saltato qualcosa?
Sembra che la #3 sarebbe una buona risposta, anche se devo riflettere sulle conseguenze di avere un tempo di logout più lungo sul sito principale.
Mi piace ancora la #1 come scelta migliore, ma poi devo capire come evitare tutti questi dannati problemi di limiti di velocità. Vorrei che ci fosse un modo per disattivare globalmente tutti i limiti di velocità in Discourse (e in nginx, dato che sto usando l’installazione Docker di Discourse), punto e basta. Non ne ho bisogno di nessuno. È solo il mio sito principale che parla con la mia istanza di Discourse. Non permetto chiavi API utente e sono l’unico a possedere una chiave API di sistema. È un sistema completamente chiuso e i limiti di velocità non fanno altro che (costantemente) mettermi i bastoni tra le ruote. Immagino che sia un argomento diverso.
Se hai bisogno di mantenere il comportamento che hai descritto, allora sì, penso che quelle siano le 4 opzioni. Ma se modifichi leggermente il comportamento, funzionerà meglio con gli strumenti disponibili.
La parte insolita della tua configurazione è:
Stai terminando la sessione di Discourse ogni volta che la sessione sul tuo sito principale scade. Se rimuovi questa parte, penso che la configurazione rispecchierà le configurazioni tipiche.
Potresti comunque chiamare /logout quando un utente esplicitamente si disconnette dal tuo sito principale. Basta non chiamarlo quando la sessione scade naturalmente.
Non si capisce dall’OP, ma stai gestendo un sito altamente specializzato dove le persone condividono informazioni super sensibili, o dove la maggior parte degli utenti accede da computer pubblici condivisi o simili?
Di gran lunga la soluzione più semplice qui sembra essere quella di non essere iper-aggressivi nell’invalidare le sessioni degli utenti e nell’obbligarli al logout. La mia preferenza come utente è sempre: “non disconnettermi mai a meno che non clicchi specificamente su esci”. Se non è possibile, potresti almeno impostarlo a un giorno o una settimana o qualcosa del genere?
Capisco, è una buona soluzione; penso che molti dei miei membri usino la casella “mantienimi connesso” nella pagina di accesso, quindi sarebbe fluido riportarli al sito principale. Se la loro sessione è scaduta sul sito principale, verrebbero (invisibilmente) riconnessi proprio in quel momento. Hmm.
È un sito per una fascia della popolazione molto sensibile alla privacy. Ma capisco cosa intendi e penso che potrei semplicemente fare come suggerisci tu (e David).
Vi ringrazio entrambi, moltissimo. Non avevo una buona visione del “quadro generale” qui, né di come altri siti gestiscono questo tipo di scenario… ora sì e vedo alcune possibili soluzioni per la mia situazione. Molto apprezzato!
e vedo alcune possibili soluzioni per la mia situazione. Molto apprezzato!