Hi there, I found that after the cookies jupyterhub-user-xxx and jupyterhub-session-id expired, i can still operate in jupyterlab. To verify this, I set
c.JupyterHub.tornado_settings = {
"slow_spawn_timeout": 0,
"cookie_options": {
"expires_days": 0.0125
}
}
c.JupyterHub.cookie_max_age_days = 0.0125
So the cookies jupyterhub-user-xxx and jupyterhub-session-id will expire after 18min,and those will delete in browser when expired. But the web page have no tips,and when i open a notebook, it can be used normally, and the cookie jupyterhub-user-xxx in the browser's cookie again.
I use GenericOAuthenticator with keycloak, and i also set the keycloak SSO Session Idle and SSO Session Max is 18min. I'm sure there's no active session in my keycloak.
I think jupyterlab or jupyterhub should disable user operation and prompt user to login again?
If i use the classic notebook, any operate will be disable or redirect to login page.

I use jupyterhub 0.9.4 and jupyterlab 0.35.4
I appreciate how you wrote this issue, I managed to grasp this quite well I think even though I'm no expert regarding these matters.
Hmmm, my current idea is that accessing your-hub.com brings you to the configurable http proxy (chp), and that in turn is configured to directly go to your singleuser server if authenticated with the hub. But, if you would force information from the hub, perhaps you would need to login again? Hmmm...
So: visiting your-hub.com/hub/home may be forbidden but visiting your-hub.com may be allowed I think, after the cookie expires, which also seems buggy to me.
My hypothesis is that we need to make sure that the hub updates the CHP based on these settings smarter, and that it currently isn't doing such updates or using some default value. Hmmm...
This is a related issue:
https://discourse.jupyter.org/t/how-to-force-re-login-for-users/1998
The problem with this is that, once you are finished spawning and dropped in the notebook, the hub never sees any HTTP requests from the user’s browser/CHP, because everything is routed to the notebook and most of it is websockets. The only HTTP requests are to the notebook server (kernelspecs, sessions, terminals, etc…), all of which is authenticated/authorized by the token in the authorization header. All other communication is done over websockets.
I think at least one of the things you want is for token in the authorization header to have a configurable validity range.
Having the same issue of expired cookies (probably) because the websocket timeout logs and "autosave failures" reported from a user. What is the right way to make single user Notebooks to either relogin after some time, or extend that cookie expiration date? (we're in a fully internal system with no internet access outside the VPN, so I am not worried about long lived cookies)
Is the c.HubOAuth.cookie_options = {"expires_days": 14} a right option to try and set? Would it affect the single user notebook cookies for people with editing tabs open for days?
I figured I'd try to summarize my own overview in order to help us think more clearly about this, but I conclude its not complete enough, so please help out complementing this overview if you can.
JupyterHub is configured with some Authenticator class, such as GitHubOAuthenticator. I believe the Authenticator class knows nothing about cookies, because it could in principle choose to ignore whatever information is passed to it, but I think OAuthenticator does know about cookies, and will use them to authenticate users who have already signed in recently, when they arrive to JupyterHub. Arriving to JupyterHub is something you do when being redirected there by the configurable proxy JupyterHub controls which sits infront of JupyterHub itself, or by explicitly wanting to visit the JupyterHub at /hub/* rather than for example /user/*.
So in other words, we possible hae JupyterHub cookies for /hub/* set by OAuthenticator for example, but then we also have the user server, either notebook, or jupyter-server. These will also require some credentials that I assume will be cookies after some interaction with the JupyterHub.
I think someone need to complement my overview regarding the authentication interaction of a notebook server and a jupyter-server server at this point. They should be configured on startup to be aware of JupyterHub, but how does the user -> user server authentication work, and how is JupyterHub involved in that?
https://discourse.jupyter.org/t/how-to-force-re-login-for-users/1998/6 is probably the best explanation
Most helpful comment
https://discourse.jupyter.org/t/how-to-force-re-login-for-users/1998/6 is probably the best explanation