Forcing logout after container stop

JupyterHub
, ,
1

We are working in an environment where we’d like the user’s information and history deleted after a container is stopped. We’ve tried a number of things so far, each of which has problems. The use case that we have is one similar to an online learning site, such as Geeks for Geeks, but with a far richer computation environment. Briefly, we want to have a web page illustrating lesson content and then a Jupyter or RStudio (instantiated from JupyterHub) embedded in an iframe. The user’s experience is anonymous and transient.
Our solution has been to pass the requested environment in as a URL argument in an iframe src tag, e.g. <iframe https://myJupterHub.myOrganization.org?config=rstudio-lesson-3/> and use an extension of TmpAuthenticator to authenticate the user and instantiate the appropriate environment by setting the spawner’s image, and, optionally, URL and cmd.
It’s worked well. But we’d like, when the single-user server is stopped or culled, for the cookies to be cleared, and the user deleted from the database. Doing a manual logout works well, but for obvious reasons an automated solution is preferred.
Our best solution so far is to work through the culler, by setting
cull:
users: true
Which will take care of containers that are culled but won’t take care of those which are shut down manually.
We’ve also tried adding a post_spawn_stop(users, spawner) method to the authenticator. Unfortunately:
a. It appears that this can be called during the initial spawn, in container failure
b. The only object which has access to the cookies directly is the handler, and sometimes spawner.handler is None.

We’ve tried adding refresh_auth to the authenticator, but this forces a login loop on initial login.
I can understand cull not clearing the cookies properly (after all, cull is a back end process that doesn’t have access to the cookies.

We’re interested in any comments/thoughts people have, particularly in a better way to clear cookies. Also, if someone can think of a better way to pass the desired image without forcing the user to go through the profileList screen, we are very interested.

We’re also prepared to contribute our code if anyone is interested in reviewing a PR.

2

If true, this would be a bug. Users who have no running servers should be culled by this logic. Can you report it to jupyterhub-idle-culler with some more debugging info on users that should be culled but aren’t?

You can select inputs with GET params or a POST body. The Spawner has access to the requesting handler via self.handler, which you can use to retrieve parameters, or the options_from_query wrapper to transform query parameters to user_options. Use with special care, because you shouldn’t allow unvalidated input because anyone can craft one of these URLs. But selecting a profile by name ought to be fine, and is in fact supported by default in kubespawner: https://hub.example.horse/hub/spawn?profile=abc

That should let you create a link to spawn a server with a specific profile with no user prompts.

3

First, thanks, for the valuable feedback, and I confirmed the behavior on manually-stopped servers. Specifically, we have a hub running at https://ezcz-hub.engageLively.com which supports anonymous login with a secret passed in the argument list (this is for testing only, we’ll do something more robust later), and a config flag. The config flag picks the profile. So to reproduce, I:

  1. Started a server with one profile
  2. Hub Control Panel > Stop My Server
  3. Started a server with a different profile

Step #3 started the server with the same profile, which shows authentication is being skipped. I am (and I admit, this is the wrong place) setting up the profile in the authenticator. The right place to do this is in the spawner.

And I want to thank you for the pointer to the spawner. I hadn’t realized I could access the handler from the spawner, and that will let us do this right.

Thanks again for all of your help.

Best
Rick