Closed bjodah closed 2 years ago
Thanks @dickmao,
I had to specify the full url, including http for ein
to open my notebook-list. i.e. http://host:port/url-base
, but then I could not open actual notebooks (complaints about _xsrf in the jupyter notebook log).
So I set out to reproduce the error in a well specified environment (using linux containers), but it turns out things actaully work just fine with recent versions of all dependencies.
Turns out there actually seems to be an issue with ein(?) in the case when a notebook server has both:
base_url
password
I updated the repository with the minimal non-working example to highlight this.
@dickmao, is it alright if I re-open this issue?
Thanks @dickmao, so far things seem to generally work for me too, did you manage to execute any cells?
Alright, I can sympathize with that. But forgive my ignorance, if you typically recommend staying away from jupyter, what would you recommend to run emacs-ipython-notebook against?
(Unfortunately I did not get to decide how I ended up in this base_url / password situtation, but rather due to draconian network/firewall rules in a multi-user environment, where I'm the emacs guy, and my collaborators prefer the web-interface...)
Oh, I'm not at all sure there's a bug in ein, I might very well be doing something wrong, or the bug resides in one of the dependencies. I really do appreciate you taking the time to look into it, especially since it works in your environment.
But that repository I linked to is pretty much a reproducible environment (short of me locking down exact version numbers pip
and package-install
downloads). Anyhow, since the environment is "fresh" each time upon running the script, the cookie file does not go stale (since there is no file at the launch of the container). Deleting it invalidates the running session (as expected I guess), but doesn't help for the next session either.
I targeted podman
(the docker replacement), here's what the session looks like:
https://asciinema.org/a/xR6fxASSDjCIRyAzqzO9NP5Jr
it's a bit opaque to me why the WebSocket session fails to authenticate, while the HTTP session, succeeds.
Your persistence has paid off against my surly dismissiveness. EIN was altogether incapable of handling a non-empty NotebookApp.base_url.
I made a bunch of changes in 6f138be and tested against your container. I had to change "0.0.0.0" to "127.0.0.1" in launch-notebook.sh
, and change "localhost" to "127.0.0.1" in launch-emacs.sh
to get it to work.
@dickmao, haha, any surliness of yours is greatly out-weighted by the tenaciousness with which you have followed up my questions and fixed this shortcoming in ein. Very much appreciated!
That commit of yours looks like some (very nice) elisp wizardry (I really should invest the time to become proficient in elisp given how much time i spend in Emacs). I will try your fix right away!
Works like a charm, thanks again!
I've searched through the source code, even though I see references to a variable
base-url
it is not quite clear to me if I can configure this in ein? Looking through cutomize-group forein
, I did not see any such setting?The use case is the following: notebook server running with
jupyter_notebook_configy.py
:And nginx is providing this to the outside world (intranet) via a reverse proxy, on port 443 (https), which matches URLs with /my-base-url:
/etc/nginx/snippets/my_jupyter_service.conf
/etc/nginx/sites-enables/my-service
$ grep /etc/nginx/sites-enabled/default
and this appears in the main `server { ... }` blockThis works great in the web browser. I'd like to access this server using
ein
too though (locally, from the machine hosting the notebook server), if I run:I get:
It feels like I'm potentially very close, and I am probably just missing something obvious. Any guidance on this issue is of course much appreciated. And thank you for your continued work on
ein
, a marvelous package in my opinion! :)