Launch dev mode of JupyterLab as a subprocess #1
Conversation
yuvipanda
commented
Jan 23, 2019
•
yuvipanda
commented
- Launches JupyterLab in dev mode
- Redirects logs to jupyterlab-dev.log
Was also missing a shebang
binder/jupyter_notebook_config.py
Outdated
| @@ -7,6 +7,7 @@ | |||
| '--dev-mode', | |||
| '--port={port}', | |||
| '--NotebookApp.token=""', | |||
There was a problem hiding this comment.
This makes me nervous. Are there any existing examples of managed servers that require some authentication?
There was a problem hiding this comment.
There are two attack vectors here:
- People accessing this from the browser without auth. This is prevented by jupyter-server-proxy (hopefully, haha!)
- People accessing this by hitting 'localhost:' from within the container using any process. There isn't any protection against this, but it maybe ok?
There was a problem hiding this comment.
Fair enough, I just wanted to flag it as a possible problem. If I try to sniff out the port of this managed server without going through the proxy, could I get unauthenticated access?
There was a problem hiding this comment.
@ian-r-rose not from your browser, no - since there's no direct port access. You can from inside the container (from a kernel or terminal, for example)
There was a problem hiding this comment.
What about from curl or python requests (from some random computer across the world)?
There was a problem hiding this comment.
@ian-r-rose yeah, those will be treated same as from your browser, and will be stopped by jupyter-server-proxy
See if the problem is dev-mode
|
@yuvipanda, happy to merge this whenever you feel it is ready, or if you want to take it over, that's cool too. |
|
@ian-r-rose yeah, not quite there yet! It works on my machine locally, but not on mybinder.org yet |
This is picked up by the dev instance of JupyterLab as well, possibly leading to infinite recursion
|
|
||
| # This seems to be explicitly needed with `pip install -e .` | ||
| jupyter serverextension enable jupyterlab --sys-prefix |
There was a problem hiding this comment.
I've run into this with serverextensions before as well. It seems the conf.d stuff doesn't get linked right with an editable install.
There was a problem hiding this comment.
I think a non -e install should work fine, however.
Doesn't seem to put templates in the right place?
Maybe this will help?
yuvipanda
changed the title
|
Ok, I see this was merged into ian-r-rose/jupyterlab, not jupyterlab/jupyterlab... So let's pretend that this was merged upstream, I have an open PR (jupyterlab#5670) that's based off of this, and I want to try it out in binder. Would I just go to https://mybinder.org/v2/gh/gnestor/jupyterlab/vdom-events and it would launch in dev-mode? That's what the code implies to me... One thing to figure out: The binder badge on the jupyterlab README links to https://mybinder.org/v2/gh/jupyterlab/jupyterlab-demo/master?urlpath=lab/tree/demo (notice jupyterlab/jupyterlab-demo repo) where all the demo notebooks are. I guess that we could add a step in the postBuild script that clones the jupyterlab-demo repo and a Are we waiting to submit a PR for this upstream? |
|
I was hoping to make a GitHub bot to post links to the right binder. Taking a look at this now... |
|
It looks like we can either create a bot that will comment on a PR with a URL to the binder or we can create a check that will look like this (at jupyter/jupyter.github.io#321):
|
|
Ooh, I had not considered a check. How would that work? We really only need a pretty simple URL templating. |
|
Wawaweewa! So I guess that we just need to submit a PR to jupyterlab and then install the bot once it's merged? |
|
Yep, that's it! I just submitted the PR. |
Fixes vega lite 4 extensions
