Closed sam-s closed 3 years ago
If
grep 100.107.210.216 ~/.emacs.d/request/curl-cookie-jar | grep username
returns nothing, which is what I expect, then you need to look at the kernel json files in jupyter --runtime-dir
on the server machine. You have claimed your server is "nothing special" but I remain unconvinced.
If it does return an entry, and that entry isn't reflected in M-x url-cookie-list
, then there's a problem in ein-websocket.el
. This seems unlikely, not because ein-websocket.el is particulary well written, but rather because there's not much that could break there.
the relevant line in ~/.config/emacs/request/curl-cookie-jar
is
data-science.k8s.region-001.p-use-1.braze.com FALSE / FALSE 0 _xsrf 2|682c5193|ZZZZ|1603214402
moreover, ein:notebooklist-login
does not ask me for a password anymore (and shows the list of notebooks).
however, url-cookie-list
fails with "No cookies are defined"
.
the kernel file created in response to the ein
request above is kernel-d84ce358-14de-4252-996c-c5f5d45188ef.json
:
{
"shell_port": 55941,
"iopub_port": 38979,
"stdin_port": 34231,
"control_port": 48685,
"hb_port": 48739,
"ip": "127.0.0.1",
"key": "a9b98a0a-dad9102e9e463e610c965357",
"transport": "tcp",
"signature_scheme": "hmac-sha256",
"kernel_name": ""
}
the chrome web interface seems to have no problems interacting with this kernel.
data-science.k8s.region-001.p-use-1.braze.com FALSE / FALSE 0 _xsrf
That's the cross-site forgery token, which is not relevant. I would rather see something like:
#HttpOnly_127.0.0.1 FALSE / FALSE 1607728889 username-127-0-0-1-8317
Thus it appears your server does not ask for a user, which would account for tornado complaining with 403, no current user.
however,
url-cookie-list
fails with"No cookies are defined"
.
That is perturbing.
the kernel file created in response to the
ein
request above is
Hmm.. that didn't help me. Maybe you could report back with the nbserver.*.json
An empty url-cookie-list
, btw, is almost certainly a showstopper. I would M-x find-library RET url-cookie
and see if you have one of the various defcustoms in there set to a suspect value in your .emacs.
#HttpOnly_127.0.0.1 FALSE / FALSE 1607728889 username-127-0-0-1-8317
#HttpOnly_data-science.k8s.region-001.p-use-1.braze.com FALSE / FALSE 1607481770 username-data-science-k8s-region-001-p-use-1-braze-com "2|1:0|10:1604889770|54:username-data-science-k8s-region-001-p-use-1-braze-com|44:XXXXX=|YYYYYY"
Thus it appears your server does not ask for a user, which would account for tornado complaining with 403, no current user.
I have a modicum of control over how the server is run. Now it is run as
jupyter notebook --port=8080 --ip=0.0.0.0 --allow-root \
--NotebookApp.iopub_data_rate_limit=1.0e10 \
--NotebookApp.iopub_msg_rate_limit=1.0e10
How do you want me to run it?
however,
url-cookie-list
fails with"No cookies are defined"
.That is perturbing. An empty url-cookie-list, btw, is almost certainly a showstopper. I would M-x find-library RET url-cookie and see if you have one of the various defcustoms in there set to a suspect value in your .emacs.
I don't set anything url-cookie-*
in my .emacs
; moreover, I run emacs -Q
so that cannot be relevant.
moreover, when I run
emacs -Q -f package-initialize --eval "(setq debug-on-error t)" --load websocket.elc --eval '(url-cookie-parse-file-netscape (expand-file-name "request/curl-cookie-jar" user-emacs-directory))'
and M-x url-cookie-list
includes
data-science.k8s.region-001.p-use-1.braze.com _xsrf 2|682c5193|ZZZZ|1603214402
data-science.k8s.region-001.p-use-1.braze.com:443 _xsrf 2|682c5193|ZZZZ|1603214402
username-data-scienc "2|1:0|10:1604889770|54:username-data-science-k8s-region-001-p-use-1-braze-com|44:XXXX=|YYYY"
I still get the same error
Hmm.. that didn't help me. Maybe you could report back with the nbserver.*.json
{
"base_url": "/",
"hostname": "0.0.0.0",
"notebook_dir": "/root/data/data-science/jupyter",
"password": false,
"pid": 1,
"port": 8080,
"secure": false,
"sock": "",
"token": "ZZZZ",
"url": "http://0.0.0.0:8080/"
}
I know as little about cookies as the next non-web programmer, but artificially parsing an old jar file is mildly suspect. It's conceivable the server insists on new cookies for each new session.
If it does return an entry, and that entry isn't reflected in M-x url-cookie-list, then there's a problem in ein-websocket.el.
So it sounds like this is the case. The jar file has the username entry, but the in-memory url-cookie-list doesn't, and worse is completely empty, which is very suspect. You should C-u C-M-x
in https://github.com/millejoh/emacs-ipython-notebook/blob/bf1ca5b9b9da84849a1a6fb1057455814c7bfa33/lisp/ein-websocket.el#L73 and see why url-cookie-store
isn't firing.
I know as little about cookies as the next non-web programmer, but artificially parsing an old jar file is mildly suspect. It's conceivable the server insists on new cookies for each new session.
this is not an old file - its mtime
is today.
If it does return an entry, and that entry isn't reflected in M-x url-cookie-list, then there's a problem in ein-websocket.el.
So it sounds like this is the case. The jar file has the username entry, but the in-memory url-cookie-list doesn't, and worse is completely empty, which is very suspect. You should
C-u C-M-x
inand see why
url-cookie-store
isn't firing.
ein:websocket--prepare-cookies
does not call url-cookie-store
directly.
cookies
is computed and has a reasonable value:
(("username-data-science-k8s-region-001-p-use-1-braze..." . "\"2|1:0|10:1604889770|54:username-data-science-k8s-...") ("_xsrf" . "2|682c5193|ZZZZ|160321..."))
ein:websocket-store-cookie
is called twice and each time calls url-cookie-store
successfully:
======================================================================
1 -> (url-cookie-store "username-data-science-k8s-region-001-p-use-1-braze-com" "\"2|1:0|10:1604889770|54:username-data-science-k8s-region-001-p-use-1-braze-com|44:ZZZ=|XXX\"" nil "data-science.k8s.region-001.p-use-1.braze.com:443" "/api/kernels/bef991cb-ed4f-4e0d-8497-0d5efb3915fd/channels" 0)
1 <- url-cookie-store: nil
======================================================================
1 -> (url-cookie-store "_xsrf" "2|682c5193|YYY|1603214402" nil "data-science.k8s.region-001.p-use-1.braze.com:443" "/api/kernels/bef991cb-ed4f-4e0d-8497-0d5efb3915fd/channels" 0)
1 <- url-cookie-store: nil
It sounds like you are continuing along the path of woe of force parsing (url-cookie-parse-file-netscape (expand-file-name "request/curl-cookie-jar" user-emacs-directory))
. I would not do this. I know the cookies are not chronologically old, but every new websocket instance may require a brand new cookie. Who knows? I certainly don't.
Starting from scratch, you said M-x url-cookie-list
was empty. I would try to find out why that is.
It sounds like you are continuing along the path of woe of force parsing
(url-cookie-parse-file-netscape (expand-file-name "request/curl-cookie-jar" user-emacs-directory))
.
no, I am not doing that.
Starting from scratch, you said
M-x url-cookie-list
was empty. I would try to find out why that is.
emacs -Q -f package-initialize --eval "(setq debug-on-error t)" --eval '(load "websocket")' --eval '(defun websocket-ensure-connected (websocket) nil)'
M-x ein:notebooklist-login RET https://data-science.k8s.region-001.p-use-1.braze.com/ RET
M-x url-cookie-list RET
==> (error "No cookies are defined")
[New Notebook]
==> (websocket-closed #s(websocket-frame :opcode pong :payload "2e9fb87e0d8ef1ea96893aa6906147a371bb\" type=\"text/c..." :length nil :completep t))
M-x url-cookie-list RET
==>
data-science.k8s.region-001.p-use-1.braze.com:443 _xsrf 2|682c5193|ZZZ|1603214402
username-data-scienc "2|1:0|10:1604889770|54:username-data-science-k8s-region-001-p-use-1-braze-com|44:XXX=|YYY"
emacs -Q -f package-initialize --eval "(setq debug-on-error t)" --eval '(load "websocket")' --eval '(defun websocket-ensure-connected (websocket) nil)'
M-x trace-function RET url-cookie-store RET
M-x ein:notebooklist-login RET https://data-science.k8s.region-001.p-use-1.braze.com/ RET
no *trace-output*
.
[New Notebook]
==> (websocket-closed #s(websocket-frame :opcode pong :payload "2e9fb87e0d8ef1ea96893aa6906147a371bb\" type=\"text/c..." :length nil :completep t))
and now *trace-output*
is
======================================================================
1 -> (url-cookie-store "_xsrf" "2|682c5193|XXX|1603214402" nil "data-science.k8s.region-001.p-use-1.braze.com:443" "/api/kernels/bef991cb-ed4f-4e0d-8497-0d5efb3915fd/channels" 0)
1 <- url-cookie-store: ((#1="data-science.k8s.region-001.p-use-1.braze.com:443" [url-cookie "_xsrf" "2|682c5193|XXX|1603214402" nil "/api/kernels/bef991cb-ed4f-4e0d-8497-0d5efb3915fd/channels" #1# 0]))
======================================================================
1 -> (url-cookie-store "username-data-science-k8s-region-001-p-use-1-braze-com" "\"2|1:0|10:1604889770|54:username-data-science-k8s-region-001-p-use-1-braze-com|44:YYY=|ZZZ\"" nil "data-science.k8s.region-001.p-use-1.braze.com:443" "/api/kernels/bef991cb-ed4f-4e0d-8497-0d5efb3915fd/channels" 0)
1 <- url-cookie-store: ([url-cookie "username-data-science-k8s-region-001-p-use-1-braze-com" "\"2|1:0|10:1604889770|54:username-data-science-k8s-region-001-p-use-1-braze-com|44:YYY=|ZZZ\"" nil "/api/kernels/bef991cb-ed4f-4e0d-8497-0d5efb3915fd/channels" #1="data-science.k8s.region-001.p-use-1.braze.com:443" 0] [url-cookie "_xsrf" "2|682c5193|XXX|1603214402" nil "/api/kernels/bef991cb-ed4f-4e0d-8497-0d5efb3915fd/channels" #1# 0])
Hum, that output looks good.
Your token is non-empty "ZZZZ". Your server should not just let you in without asking for it.
I've seen inconsistent behaviors when invoking the server with --ip=0.0.0.0
. If you omit that switch will the server
?
I am approaching the limits of what I can advise remotely. On-site troubleshooting is possible for a nominal fee.
Your token is non-empty "ZZZZ". Your server should not just let you in without asking for it.
this is the token in nbserver-1.json
, it was asked the 1st time I used ein
to connect to this server, then it was saved in request/curl-cookie-jar
and never asked again.
I've seen inconsistent behaviors when invoking the server with
--ip=0.0.0.0
. If you omit that switch will the server
- require the ZZZZ token, and
- stop complaining about 403
I have been using --ip=0.0.0.0
since times immemorial; never had a problem.
moreover, I do need to supply something there, otherwise only local connections would be allowed and I am very much remote there...
I can force being asked for the token by removing curl-cookie-jar
...
I am approaching the limits of what I can advise remotely. On-site troubleshooting is possible for a nominal fee.
The fee is probably not a problem, access is.
I would be surprised if deleting the cookie jar suddenly caused the server to require ZZZZ. My understanding was the "token" has nothing to do with the cookie business. Either way, it would be instructive to know if a server requiring ZZZZ is better behaved (doesn't 403).
huh, I renamed cookie jar and repeated https://github.com/millejoh/emacs-ipython-notebook/issues/754#issuecomment-726364156
I was asked for password, I entered 288XXXX
, found in nbserver-1.json
.
Here is *trace-output*
:
======================================================================
1 -> (url-cookie-store "username-data-science-k8s-region-001-p-use-1-braze-com" "\"2|1:0|10:1605223426|54:username-data-science-k8s-region-001-p-use-1-braze-com|44:ZmIXXXX=|eb5XXX\"" nil "data-science.k8s.region-001.p-use-1.braze.com:443" "/api/kernels/d84ce358-14de-4252-996c-c5f5d45188ef/channels" 0)
1 <- url-cookie-store: ((#1="data-science.k8s.region-001.p-use-1.braze.com:443" [url-cookie "username-data-science-k8s-region-001-p-use-1-braze-com" "\"2|1:0|10:1605223426|54:username-data-science-k8s-region-001-p-use-1-braze-com|44:ZmIXXX=|eb5XXX\"" nil "/api/kernels/d84ce358-14de-4252-996c-c5f5d45188ef/channels" #1# 0]))
======================================================================
1 -> (url-cookie-store "_xsrf" "2|046f02b3|01ff161c84d0637bae97d257f35e12c4|1605223410" nil "data-science.k8s.region-001.p-use-1.braze.com:443" "/api/kernels/d84ce358-14de-4252-996c-c5f5d45188ef/channels" 0)
1 <- url-cookie-store: ([url-cookie "_xsrf" "2|046f02b3|01ffXXX|1605223410" nil "/api/kernels/d84ce358-14de-4252-996c-c5f5d45188ef/channels" #1="data-science.k8s.region-001.p-use-1.braze.com:443" 0] [url-cookie "username-data-science-k8s-region-001-p-use-1-braze-com" "\"2|1:0|10:1605223426|54:username-data-science-k8s-region-001-p-use-1-braze-com|44:ZmIXXX=|eb5XXX\"" nil "/api/kernels/d84ce358-14de-4252-996c-c5f5d45188ef/channels" #1# 0])
note that the password/token (288XXX.....) is not in the cookie jar. and, of course
(websocket-closed #s(websocket-frame :opcode pong :payload "2e9XXXX\" type=\"text/c..." :length nil :completep t))
2e9XXX is not in the jar either...
Sorry, I can't help you. It'd be a moderate hassle but replicating the server configuration onto your local laptop and attempting to replicate the problem wholly on one machine might be very instructive.
I would be surprised if deleting the cookie jar suddenly caused the server to require ZZZZ.
That's what did happen!
My understanding was the "token" has nothing to do with the cookie business.
My understanding is that when a server authenticates a user, it sets a cookie on the client which the client is supposed to submit in all future communications in lieu of re-authentication (this is why intercepting cookies is so dangerous). @ahyatt - could you please confirm?
Either way, it would be instructive to know if a server requiring ZZZZ is better behaved (doesn't 403).
No change.
My understanding was the "token" has nothing to do with the cookie business.
Ah, you're right. The above statement is a complete falsehood.
just to make it clear - the problem is HTTP 403 error when connecting to jupyter server behind a proxy
Are you familiar with https://github.com/ahyatt/emacs-websocket/issues/73? Right now websockets don't work correctly with the rest of emacs connection proxying. There's a fix, but it's kind of half-baked at the moment. You can try the pull request in the fix and see if it helps you.
About server authentication & cookies - this really depends on what exactly the server is doing. Normal HTTP authentication doesn't use cookies, but does requires the Authorization
header to be included on each request. However, I'm sure there are many variants, and I'm not super well informed about them.
You should authenticate via whatever HTTP method your server supports at the beginning of the websocket session. Further communication shouldn't need anything, and it's only needed again when you re-connect. Those re-connections should be rare, since the websockets can last a while.
Problem description
When I click on
New Notebook
, I get the following remote logsand backtrace
Steps to reproduce the problem
had to do
to work around https://github.com/ahyatt/emacs-websocket/issues/75
System info: