… it would also be great, if this works together with SSO systems like SAML. Means, if a user is logged out from discourse because of session timeout or browser is closed, it should send a logout request to SAML.
Would anyone be able to tell me if there is a relationship between the “maximum session age” setting, and how Google Analytics determines a “session.”
My users were complaining about having to log in daily, so I extended the “maximum session age” rather liberally, as a test to see if I’d get more return-activity from people receiving the weekly digest e-mail if they didn’t have to log in to participate.
The number of Community sessions in Google Analytics has dropped dramatically, beginning around that same date. I’m needing to know if my change, allowing people to stay logged in for longer, single sessions, equals fewer sessions reported by Google Analytics.
No, those only affect the expire data our cookie.
We ship with a month long session by default, why did you change it to a lower value? It does increase the barrier to participate and it’s quite annoying for recurring visitors.
Can’t see how those can affect each other.
Thanks @Falco! Glad to know this isn’t my fault!
I’m not the original admin, so I can’t answer that, although I remember some early discussions among our staff about aligning the timing with our SSO timing.
I also totally agree that this is, in most cases, a per user feature (some exceptions are banks and related stuff).
There really is. In a non-discourse site I have, for social logins we persist sessions (because if the user is already logged in that specific social network, there is a good chance that it’s not a shared computer, although there’s no way to be sure).
In any case, the best thing to do when the user wants the session to be expired after he/she stops using the machine is using incognito mode (which is very easy to do, even for non-technical users, as long as they know about this browser feature).