鈥⒙燗dd option to timeout session when window is closed
鈥⒙燗dd session timeout by time
Instead of onbeforeunload, maybe it would be more reliable to use cookies that expire on browser close: http://stackoverflow.com/questions/2537060/can-a-cookie-expire-when-either-some-time-passes-or-browser-is-closed
@lukevmorris I explored this when I implemented the feature in Enterprise Web because I like the solution better, but Chrome will only expire session cookies once _all_ windows have been closed, not on tab closure. onbeforeunload fires when tabs close :-/
Ah ok, TIL. I did a quick spike with onbeforeunload. Things to note:
target="_blank" (i.e. that cause a navigation in the same tab)So I guess we'll have to write some custom detection code to isolate the third case? Assuming we can do that, we should probably avoid putting an AJAX request in the body of onbeforeunload --
maybe it will do the trick to just delete the cookie clientside?
And where do we want the user to select this option, of timing out the session when closing their browser tab? Is it via the CLI? Or are we adding something to the UI?
We've now added the ability to configure your Chronograf server's session duration via the CLI on branch 1095-cookie_duration. You can export SESSION_DURATION=0 to make cookies expire on browser close.
Seems like it'd be via the CLI, when making your chronograf server, and that the server would then communicate that to the client somehow, such as via a flag on the auth object.
Here are the two most relevant resources I've found on the matter:
But even the solution from 1 above, which is the only reliable-appearing one that I've seen (which can successfully infer the difference between a tab close and a refresh), still basically uses a heartbeat.
Thoughts?
馃挀 sounds good to me.
@lukevmorris Could you specify what you love that sounds good? :)
Oh, you mean heartbeat sounds good. got it! 馃憤 馃帀
@jaredscheib I think we could run the heartbeat through the /me endpoint. I'm thinking the /me endpoint would check the validity of the cookie and reissue it with a soon to expire timeout... I think that is what is mentioned on stackoverflow.
... to add to this... the ideas on stackoverflow assume a single server that have disconnect threads running. I'm thinking we won't use that but rather have short lived cookies.
After discussion, Chris and I are thinking of making SESSION_DURATION=0 cause the server to send a cookie with a token valid for ~2 minutes, which will renew every heartbeat. Though they could also simply set their session duration to 2m -- would this be any different, @goller ?
This would mean that if a user closes a tab (not the whole browser) for more than 2 minutes, their session will have expired and they'll need to log in again. But it also means that if they close a tab and re-open it within that 2 minutes, they'll still be logged in. Is this ok behavior, @nhaugo ?
I'd be happy with this behavior ^
"We've now added the ability to configure your Chronograf server's session duration via the CLI on branch 1095-cookie_duration. You can export SESSION_DURATION=0 to make cookies expire on browser close."
This won't work, there needs to be two variables to set, one for session duration and one specifically for on browser close.
We need to account for those who want an open browser to never log out but if closed is logged out. This is needed for presentation mode.
FWIW two configuration options is what I did in Enterprise Web as well.
Recap from @nhaugo discussion:
Per further discussion with @nhaugo , logging out on tab close is not a requirement of the spec. Browser session duration is sufficient. So a heartbeat will not be necessary for this purpose. That being said, a heartbeat should still be implemented to force navigation to /login when a user's auth expires.
We will only introduce one new env var: SESSION_DURATION.
Most helpful comment
Recap from @nhaugo discussion: