-
Notifications
You must be signed in to change notification settings - Fork 301
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
XSRF cookie not always set on first request #746
Comments
Hi @davidbrochart thanks for reporting this! I also think the cookie should be set in the first GET request, but I may be missing some context, so I'll bring this issue up in this week's Jupyter Server meeting and figure out next steps. Do you know if issue also exists in |
Good point, there is no issue with classic Notebook, i.e. a first GET request to |
Hi @davidbrochart were you able to check if the change history/commit messages between |
Hey @mwakaba2, no I didn't find any reference to XSRF in Jupyter Notebook: https://github.com/jupyter/notebook/search?q=xsrf. |
I have looked into this issue. Checking the implementation, I found that the Therefore, For example, I suggest the following fixes.
I think that XSRF cookies should be checked because it is more secure than the current situation that files can be viewed via the API. However, for users who need to launch without setting a token, this could break compatibility, so please consider and review. |
Sorry, I didn't examine the proposed fix enough. After calling check_xsrf_cookie(), access to the API (e.g. http://localhost:8889/api/sessions) fails with "Blocking request from unknown origin". It is not desirable because it is difficult to understand the intent of the code, but I have confirmed that the
If there is a better way, I would appreciate your advice. |
Thanks for looking into this @reoono. |
That is certainly true. I misunderstood the issue as I proceeded with the investigation.
It seems _xsrf token is implemented with lazy initialization.
Thank you for the advice.
|
On a different note, when I access |
When launching
|
I am very sorry, I was working on branch 1.x. |
As the error message indicates, Therefore, it has been confirmed that JupyterLab works by implementing as follows.
|
I am sorry for the repeated questions. Just to be sure, I have reproduced the case where the
|
Thanks @reoono for pushing on this. |
I just wanted to show that not deleting the xsrf cookie on logout is not a particularly big problem as before.
Thanks for your kind attention.
|
I'm the maintainer of Tornado and I've been reviewing our XSRF protection recently. The PR https://github.com/reoono/jupyter_server/pull/1/files looks good to me - you need to access However, there may be an even simpler solution. Setting |
Description
With JupyterLab, a first GET request to
http://localhost:8889/lab?token=the_token
sets a_xsrf
cookie. But if the first request is insteadhttp://localhost:8889/api/contents/file.txt?token=the_token
, wherefile.txt
is an existing file, then no_xsrf
cookie is set.Reproduce
jupyter lab --no-browser
token
):http://localhost:8889/api/contents/file.txt?token=the_token
_xsrf
cookie is set in the response.Expected behavior
Shouldn't the
_xsrf
cookie always be set on the first GET request (if not already present in the cookies)?Context
The text was updated successfully, but these errors were encountered: