This generates a cookie for the user, such that the url http://220.127.116.11:8888 does not require the token later on.
When the instance is destroyed, and a new one is created using the same IP address but on a different server, I am able to login with the existing cookie in my browser using the url without token, no token is requested. Removing the cookie disables access to the server.
I see no reason how this is happening, the instances are created from the same base image but are deployed on different servers. I confirmed that the token generation was different on every occasion.
The token is set in jupyter_notebook_config.py with
“c.NotebookApp.token = ‘45711f4141c6630d1370e0b687f2ac93’”
Forgive me, I might be all wet, but here goes. . . .
Note that this is not based on my experience with Jupyter, (I have virtually none), but with my experience using client-server authenticated sessions.
This kind of process - in general - creates a token that binds a particular machine/browser/whatever with a particular server IP address. Jupyter appears to be doing the same thing, and doing it in the same general way.
It does this by generating a unique token, embedded into a persistent cookie, that is used to demonstrate if this particular user/browser has successfully authenticated here before.
In other words, I have machine “X”, and I go to your server at 18.104.22.168:8888. When I do this, the server system generates a unique token that associates my machine with your server located at 22.214.171.124. Even if that IP is a “front-end load balancer”, the association is between my specific machine and the server(s) located behind that particular IP address.
If I break that connection and then re-connect, I would expect that I would not need a new token because I have already been associated with that particular “server” (i.e. IP address) and the persistent cookie containing that token proves I’ve been there.
That’s what these things are supposed to do, and, (as far as I can tell), the behavior is exactly what I would expect to happen.
In your case it might not matter; but you should pay attention to this when using any kind of token/cookie based authentication method.
Perhaps you can explain what you want to be happening and why it needs to be happening that way?
A better description of what you want to accomplish and how you expect it to work, might help those who know more about this guide you.
Thanks for your reply.
Our goal is to setup jupyter notebook servers automatically.
The desired result is that when a different user receives a notebook server, we do not wish that previous users of a notebook server on that IP can get access.
Eventually we would embed it in an IFrame.
For now it seems we can prevent our issue by using setting c.NotebookApp.cookie_secret.
Would we be better off setting a random password instead? It seems the token remains valid also after setting a password.