User automatic logout on inactivity

JupyterHub
1

Hi everyone,

I’m currently trying to open a Jupyterhub instance deployed in my organization HPC cluster wide open on the internet. The final security requirement I have to answer is that users should be automatically logged out if they are inactive for more than say 10 minutes.

I’ve searched a bit for a solution to this, but did not find anything yet:

Is there any other solution?
Does the spawned notebook periodically checks with the hub if authentication is still valid?
Is it possible to implement something like this somewhere?

Thanks in advance,
Guillaume.

2

Hi, Have you taken a look into the culling options? They sound close to what you need.

3

Thanks for the answer, but as stated in the culling docs:

This means that leaving the computer running with the JupyterHub window open will not be treated as inactivity.

Which is precisely what I need. So culling won’t do it.

4

Yeah, that portion of the doc kinda surprised me as well. Culling at that level doesn’t strike me as very useful because of that.

For completeness, culling can also be configured within a Notebook server. In this case, the target of the culling operation is the kernel itself. In addition, there are more options - like culling connected kernels (probably what you’re after), or culling busy kernels (which I wouldn’t advise). See the options on MappingKernelManager. Since I believe you’re focusing primarily on resource consumption this may help, although I suspect the issue is the Notebook server itself. You need it to go away.

PS. Your links in your original post should be edited to not include the trailing colon.

1 Like
5

Nope, I’m actually focused on preventing a malicious user to take control of a running Jupyterlab. I don’t care that the notebook server keeps running behind the scene, I just want the user to be disconnected if he is away from keyboard more than 10 minutes. That’s why I think culling is not what I’m after.

6

It seems I can’t edit my original post, not sure if this is a discourse trust level problem or something else…

7

So I also ran into https://github.com/jupyterhub/jupyterhub/issues/1780. This is what I would need: close open websocket connections upon logout.

I’m able to logout automaticaly from the hub, and also to prevent new access to /users/* after logout thanks to F5 technology in front of the hub.

But already open jupyterlab interface and specificaly open notebooks or terminals will continue to work.

Is there any way to force jupyterlab to do a page reload or any API I could use to check if login is still valid on notebook server side?

Ping @minrk if you have any advice?

8

I’ve fixed the links for you

9

Ok, so the solution of using F5 tech provided functionality is actually not working. Leaving the browser tab open on Jupyterlab will never trigger a timeout as the JavaScript application continuously issues http requests, so it is always seen as active as long as the browser tab has focus.

The only solution I see currently is to implement some kind of plugin which checks for inactivity on the client side, and automaticaly redirects to logout page if user doesn’t touch its mouse or keyboard during a given period.

Does that sounds feasible ?

Cc @minrk who already gave precise answers to questions like this one.

10

The Jupyterlab plugin solution does work in our case. We’ll soon share it on github, once it’s better tested, so that anyone can benefit from it!

2 Likes
11

@guillaumeeb we have the same challenge (enterprise context, strict security requirements to session TTL, etc). At current stage of research looks like a custom extension is the only way to implement proper session management (without forking/hacking the lab code itself).

Did you end up release your solution by chance?

12

Hi @oleksandr,

We’ve not released it yet, but I can share the code here first, it’s pretty simple. I’ll try to do it next week !

13

Hi! Thanks for reply. Would be great to take a look into the code as well!

14

Here is a snippet of the extension code:

module.exports = [{
    id: 'autologout-labextension',
    autoStart: true,
    activate: function(app) {
      console.log('JupyterLab extension autologout-labextension is activated!');

      var timeoutInMiliseconds = 1800 * 1000;  // 30'
      var timeoutId;
      var lastTrigeredTime = 0;

      function startTimer() { 
        timeoutId = window.setTimeout(doInactive, timeoutInMiliseconds);
      }

      function resetTimer() {
        // Timer reset every 10 seconds on event trigered
        if (Date.now() - lastTrigeredTime > 10000) {
          console.log("[autologout] logout timer reset");
          lastTrigeredTime = Date.now();
          window.clearTimeout(timeoutId);
          startTimer();
        }
      }

      function doInactive() {
        console.log("[autologout] logout trigered due to user inactivity");
        window.location.href = "/hub/logout";
      }

      function setupTimers () {
        document.addEventListener("mousemove", resetTimer);
        document.addEventListener("mousedown", resetTimer);
        document.addEventListener("keypress", resetTimer);
        document.addEventListener("touchmove", resetTimer);
         
        startTimer();
      }

      setupTimers();

    }
}];

I’ll try releasing as soon as possible.

1 Like
15

@guillaumeeb thanks! simple indeed!

although i have immediate feature request :smiley: as we usually deal with strict security requirements which introduce also max session TTL (regardless idle time). i can imagine a configurable session’s endpoint to call periodically and validate 401/403 status code…

16

Happy to contribute as soon as there’s the basic code is that makes sense.

17

Thanks for the useful solution. The question remains: is it possible to implement it to “Classic” Jupyterhub ? Not to Jupyterlab.

18

Only just found this thread and it is super cool to see how short the code is!

Some nitpicking on language: JupyterLab and classic Jupyter notebook are two different frontends that can be used with JupyterHub. This means there is no “classic JupyterHub”, only “classic Jupyter notebook”.

It would be cool to make a official package that is simultaneously a classic notebook and JupyterLab extension to get this functionality on both types of frontend.

I’m thinking we should make a variation of this extension for mybinder.org that shows users the (approximate) time remaining before their session will end (if they are getting close to the end). WDYT @manics?

19

Sounds like an idea! With JupyterLab 3 it should be possible to have a pip-installable extension, and I’m hoping it’s possible to bundle the jupyter-notebook extension in the same package. It’s on my todo list to investigate…

If you’re publishing a JupyterHub extension what would be ideal from the mybinder.org point of view is if it could be customised if necessary, or perhaps extended i.e. use your extension as a library. I’ve no idea how to do that with JupyterLab though.

1 Like
20

Hi all,

Anyway, if the mecanism could some way be put on Jupyterhub side, this would be great, but I did not found any simple solution.

The problem with the Jupyterlab or classic notebook extension is that if you propose a platform where users can customize and run their own Jupyterlab, you cannot easily ensure that the extension is installed…

So just wanted to ask if someone had an idea on how to put such a verification on Jupyterhub side?