-
Notifications
You must be signed in to change notification settings - Fork 307
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New anon users generated ad infinitum when using IdentityProvider token #1245
Comments
Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗 |
cont. Troubleshoot Output❯ jupyter troubleshoot $PATH: ~/software/anaconda3/envs/ve_iaa_pytorch/bin ~/software/anaconda3/condabin ~/software/texlive/bin/x86_64-linux ~/software/node-v12.14.0-linux-x64/bin /cm/shared/openmind/gcc/11.1.0/bin /usr/lib64/qt-3.3/bin ~/me/zsh/bin ~/me/vim/bin ~/me/tmux/bin ~/me/git/bin /usr/local/bin /usr/bin ~/bin /usr/local/sbin /usr/sbin |
@daeh |
Hi! In the stackoverflow question, someone suggested setting LAB_TOKEN="test". |
Use The
Notes:
|
Hi everyone! Sorry for not getting back to you sooner. Jupyter-Server v1 was a stateless single-user server. With the introduction of real-time collaboration in JupyterLab, we needed to track different users connecting to the same instance. For this reason, in Jupyter-Server v2, we introduced a new identity API. This identity API was designed to enable third-party extensions to swap the IdentityProvider. The default implementation of Jupyter-Server is a stateless single-user server yet. With the default authorization, you can configure the server to use a password or a token, but it is the same for every user. Furthermore, since this is a stateless server, the default implementation of the identity provider uses cookies to track sessions, assuming every new session is a different user and generating random anonymous user identities. You can find more information here. If you are using the default implementation, every time a client connects (either using a password or token authentication), we check whether there is a cookie with a user identity. If the cookie is absent, we generate a new random identity for that client and store it in a cookie. To avoid generating a new user for each request, you must habilitate cookies in your client. I'm not entirely sure, but VS code might have a flag to enable cookies for remote sessions. |
thanks for the detailed explainer, @hbcarlos Am I interpreting this right --- that you don't see a fix for anon token-auth coming from jupyter-server? Rather you're advising us to take the issue up with VS Code? |
I think your interpretation is correct, but I would like first to further discuss and get inputs from other on this. I will try to join next week jupyter server dev meeting to have more opinions on this. |
Hi @daeh. I'm sorry for not getting back to you sooner. I'm very busy at the moment. It was not. Actually, I've been trying to reproduce the issue by following your description. Unfortunately, I'm not able to reproduce it. This is what I tried: Attempt 1:I used VSCode as a client to open a local notebook and connect to a remote kernel running on Jupyter Server on a different machine (the remote server is on the same network as my laptop).
This works as expected. It does not generate multiple users. Attempt 2:I connected to a JupyterLab instance in a remote server using ssh port forwarding.
This works as expected. It does not generate multiple users. I was using: Can you confirm you are using the latest version of VSCode and VSCode Jupyter extension? If that's the case, is your remote Jupyter server running under a proxy? |
I have tested on my vscode connecting a notebook to a running jupyter server and it looks working fine as a user (I can run the notebook cells). The server log show the following, is that expected?
|
This previous has been run on VSCode Version: 1.76.2 (Universal) (Date: 2023-03-14T17:54:09.061Z (4 wks ago)) and jupyter server 2.6.0.dev0 |
@daeh We discussed it again during the server weekly meeting. This is an issue with VSCode, not with Jupiter Server. Jupyter Server uses cookies to authenticate clients, as described in the documentation. Once you logged in with the token, the server will set a cookie, and the token is no longer necessary.
I finally managed to reproduce it. In VSCode, there are two ways of connecting to a remote kernel. The first one and the one described in the VSCode documentation is by setting the URL, including the token, to a running Jupyter Server The second option consists of setting the URL without the token, then VSC will show another prompt requesting the token. In this case, VSCode will store the cookie and use it on each request. |
In case somebody from the VSCode looks at this, one theory about what's happening is that when the user is presented with the challenge/response for authentication, the extension holds on to the cookies generated by the server, but when the extension receives a valid response by passing in the token, the extension might not be respecting the sessions cookies set by the server. So for end users who experience this behavior, the current workaround is to not pass the URL containing the token to VSCode and instead allow the extension to ask them for it – until this issue is resolved upstream. |
I think so, and report it to microsoft/vscode-jupyter#13345 |
What is the name of the cookie that Jupyter Server sets to track sessions? I am running the server behind a proxy and some cookies are stripped by the proxy. So I want to make sure that these session cookies are not stripped and they go through. I checked the links to the documentation and the cookie name is not mentioned as far as I can tell. |
Description
It's possible that I'm just doing something wrong but this behavior seems related to other issues so I'm posting it as a bug.
I'm using SSH port forwarding to execute code from VS code on a mac with a remote jupyter kernel on a Centos HPC. I was previously using
jupyter notebook --no-browser --port=$ipnport --ip=$ipnip
and a notebook token. I updated to jupyter-server v2 and now when I connect to the remote kernel, the server makes a new user every second or so, for as long as the connection is open:This looks to be related to #1033, as well as jupyterlab/jupyterlab#13432, both of which were resolved by #1076. But I seem to not be the only one experiencing this issue recently (e.g. jupyter/docker-stacks#1892 , NorESMhub/noresm-land-sites-platform#169 , https://stackoverflow.com/questions/75830256/jupyter-spam-with-generating-new-user-for-token-authenticated-request-in-logs )
Reproduce
I'm using
c.IdentityProvider.token = '...'
in.jupyter/jupyter_server_config.py
andjupyter server --no-browser --port=$ipnport --ip=$ipnip
to open the connection.I have tried numerous other configs but nothing seems to change the behavior. E.g.
jupyter lab --no-browser --port=$ipnport --ip=$ipnip --ServerApp.password='' --ServerApp.jpserver_extensions="nbclassic=False" --ServerApp.tornado_settings='{"headers": {"Content-Security-Policy": "frame-ancestors *"}}'
shows the same behavior.Expected behavior
For jupyter server to create one user when the connection is established rather than a new user every second-ish.
Context
Remote kernel running on Centos 7.7.1908, in conda env.
Locally I'm using VS Code on MacOS 12.6.3
The troubleshooting output is too long to fit here, I'll post below
Command Line Output
The text was updated successfully, but these errors were encountered: