Restrict Endpoint Access

[Alexander Feiszli]

Hello, 

At my org we are looking to implement Jupyter notebooks in production as sort of "mini-apps" for small groups of end users. The idea is that the data scientists can develop in Jupyterhub like an IDE and then push a notebook into a CICD workflow, and then out pops a production version that is accessible by a particular group of users. The reason for this is that the data scientists are not app developers, they do not want to write webapps, just work on their algorithms, and their end users are very small groups, maybe 6-12 internal users, so it is unnecessary to have a development team devoted to making nice looking apps for every algorithm they write. We just need a mechanism by which the end user can provide input data, it gets transformed by the notebook, generates some charts/graphs, and then they receive transformed output data.

For the end users, they should not be able to modify or create new notebooks, simply run a single notebook. For that reason we are looking at the "appmode" plugin (https://github.com/oschuett/appmode). The next thing we would like to do is have the production URL redirect to the running "appmode" version of the notebook. In addition, the production notebook server should basically just have all the other endpoints shut off or restricted, so that only this single "appmode" page is accessible.

Can someone point me in the right direction for how I could modify a notebook server to have requests to the base url redirect to this appmode page, and how to restrict or turn off the other endpoints? I am a bit lost but guessing I will need to modify the handlers here: https://github.com/jupyter/notebook/blob/master/notebook/notebook/handlers.py

[Chris Holdgraf]

Check out Voila! ( https://github.com/QuantStack/voila)  I bet that you'd find it interesting - it's quite similar to app mode :-)

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+u...@googlegroups.com.
To post to this group, send email to jup...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/d290d0dd-151e-4af0-a59c-e3cd38f78ccf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexander Feiszli]

That's exactly what I'm looking for! 

I'm trying to figure out how to use this now; there's very scant documentation which makes this a little difficult.

I'm running:

pip install voila

jupyter nbextension install voila

and get

FileNotFoundError: [Errno 2] No such file or directory: 'voila'

Do you know the apporpriate name/path to point to?

Also, I believe this would be even more valuable running as a standalone application, but that I think would be even more challenging to set up without documentation. Do you know of any references I can look at?

Thank you!! This extension looks very valuable.

On Wednesday, April 17, 2019 at 10:05:25 AM UTC-5, Chris Holdgraf wrote:

Check out Voila! ( https://github.com/QuantStack/voila)  I bet that you'd find it interesting - it's quite similar to app mode :-)

On Wed, Apr 17, 2019 at 6:54 AM Alexander Feiszli <alex....@gmail.com> wrote:

Hello, 

At my org we are looking to implement Jupyter notebooks in production as sort of "mini-apps" for small groups of end users. The idea is that the data scientists can develop in Jupyterhub like an IDE and then push a notebook into a CICD workflow, and then out pops a production version that is accessible by a particular group of users. The reason for this is that the data scientists are not app developers, they do not want to write webapps, just work on their algorithms, and their end users are very small groups, maybe 6-12 internal users, so it is unnecessary to have a development team devoted to making nice looking apps for every algorithm they write. We just need a mechanism by which the end user can provide input data, it gets transformed by the notebook, generates some charts/graphs, and then they receive transformed output data.

For the end users, they should not be able to modify or create new notebooks, simply run a single notebook. For that reason we are looking at the "appmode" plugin (https://github.com/oschuett/appmode). The next thing we would like to do is have the production URL redirect to the running "appmode" version of the notebook. In addition, the production notebook server should basically just have all the other endpoints shut off or restricted, so that only this single "appmode" page is accessible.

Can someone point me in the right direction for how I could modify a notebook server to have requests to the base url redirect to this appmode page, and how to restrict or turn off the other endpoints? I am a bit lost but guessing I will need to modify the handlers here: https://github.com/jupyter/notebook/blob/master/notebook/notebook/handlers.py

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jup...@googlegroups.com.

[Alexander Feiszli]

Also, it says the notebook is "Read Only" in the docs. I would still like users to be able to provide input datasets via widgets. Is this disabled?

[Tim Paine]

Widgets are enabled

Tim Paine

tim.paine.nyc

To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+u...@googlegroups.com.

To post to this group, send email to jup...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/dfef1a67-4345-44a8-a1da-af5565499d47%40googlegroups.com.

[Chris Holdgraf]

More specifically - one of the goals of Voila is to be more secure. A good default for this is to prevent the user from running arbitrary python code, and keeping their interaction at the javascript layer (which is what widgets are all using). 

You can find a few cool examples here: https://mybinder.org/v2/gh/QuantStack/voila/stable?urlpath=voila/tree/notebooks

The reason you don't see a ton of docs is because Voila is still in early development mode, but I have heard docs are coming :-)

To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/FA474923-AA9D-4C0B-9BF8-C5D19E1DF8D1%40gmail.com.

[Alexander Feiszli]

Thank you Chris, that is exactly what we are looking for as well, disabling the ability to run arbitrary code.

Do you happen to have the instructions for installing and enabling the extension handy? I'm not getting it quite right.

On Wednesday, April 17, 2019 at 11:17:56 AM UTC-5, Chris Holdgraf wrote:

More specifically - one of the goals of Voila is to be more secure. A good default for this is to prevent the user from running arbitrary python code, and keeping their interaction at the javascript layer (which is what widgets are all using). 

You can find a few cool examples here: https://mybinder.org/v2/gh/QuantStack/voila/stable?urlpath=voila/tree/notebooks

The reason you don't see a ton of docs is because Voila is still in early development mode, but I have heard docs are coming :-)

On Wed, Apr 17, 2019 at 9:08 AM Tim Paine <t.pa...@gmail.com> wrote:

Widgets are enabled

Tim Paine

tim.paine.nyc

To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/dfef1a67-4345-44a8-a1da-af5565499d47%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jup...@googlegroups.com.
To post to this group, send email to jup...@googlegroups.com.

[Chris Holdgraf]

Hmmm, I've only ever followed the instructions here:  https://github.com/quantstack/voila#installation

if those don't work, try opening an issue in the voila repo? I'm sure they'd appreciate feedback on what's confusing!

To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+u...@googlegroups.com.

To post to this group, send email to jup...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/dd259805-b04f-4ab6-b54f-190d783e8eea%40googlegroups.com.

[Jonathan Larkin]

I have a similar problem to Alex (a small team, limited dev resources, limited experience in front end dev, etc. and about 10 users who consume the output). I note that Alex mentioned *JupyterHub*. I would imagine this is a very common problem. I am jealous of R/Shiny for this kind of workflow.

I have just started using `appmode` and it is pretty nice. This is what I do:

- In development, I use JupyterHub and DockerSpawner to spin up Jupyter singleuser servers (e.g., I develop on an image called mysingleuserserver).

- When I want to release a notebook to prod, I just git pull it over on the JupyterHub server to /srv/jupyterhub/home/prod (a user named "prod").

- For the end users: I don't want the user to need to interact with JupyterHub because then the user has to 1) log into JupyterHub, and 2) Spawn a server, and 3) then apply the `babeurl/apps/foo.ipynb` link in their browser. This is too clunky for a non-technical user. So for prod, I spin up a single user server (docker run --detach --name appmodesrv --restart always -v /srv/jupyterhub/home/prod:/tmp/working -w=/tmp/working -p 8888:8888 -it mysingleuserserver jupyter notebook --no-browser --allow-root --ip="0.0.0.0" --notebook-dir=/tmp/working --NotebookApp.token=''"). Then the users just point to mydomain:8888:/app/MyApp1.ipynb. All good! 

To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAD7kTDF4VSFOZMbip6oizN4FUiNyg9AbMq_o1SiNfDWTXqeCdg%40mail.gmail.com.

[Jonathan Larkin]

That should be:

docker run --detach --name appmodesrv --restart always -v /srv/jupyterhub/home/prod:/tmp/working -w=/tmp/working -p 8888:8888 -it mysingleuserserver jupyter notebook --no-browser --allow-root --ip="0.0.0.0" --notebook-dir=/tmp/working --NotebookApp.token=''"  --Appmode.show_edit_button=False

[Simon Biggs]

This seems to be hitting a similar set of aims to what scripedforms set out to do, except you have managed to focus on security and support Jupyter widgets.

Would you be open to me marking scripedforms as deprecated and point users to your repo/package?

[Alexander Feiszli]

Hi Jonathan, I went on a bit of a wild goose chase with Voila. While it has some options that I find superior to appmode, it's just not viable for us at this point. Or if it is, the documentation simply does not exist to make it work with our use case.

That said, I'm going to look into your approach using appmode. I've got it running without the edit button and it looks great. The only thing is, we do not want end users to be able to navigate to the file browser (let's say they figure out the correct url suffix) and access the underlying source code (in some cases this information is a bit sensitive). Does your approach restrict access to the file browser?

On Wednesday, April 17, 2019 at 11:57:45 AM UTC-5, Jonathan Larkin wrote:

That should be:

docker run --detach --name appmodesrv --restart always -v /srv/jupyterhub/home/prod:/tmp/working -w=/tmp/working -p 8888:8888 -it mysingleuserserver jupyter notebook --no-browser --allow-root --ip="0.0.0.0" --notebook-dir=/tmp/working --NotebookApp.token=''"  --Appmode.show_edit_button=False

On Wed, Apr 17, 2019 at 12:50 PM Jonathan Larkin <jonatha...@gmail.com> wrote:

I have a similar problem to Alex (a small team, limited dev resources, limited experience in front end dev, etc. and about 10 users who consume the output). I note that Alex mentioned *JupyterHub*. I would imagine this is a very common problem. I am jealous of R/Shiny for this kind of workflow.

I have just started using `appmode` and it is pretty nice. This is what I do:

- In development, I use JupyterHub and DockerSpawner to spin up Jupyter singleuser servers (e.g., I develop on an image called mysingleuserserver).

- When I want to release a notebook to prod, I just git pull it over on the JupyterHub server to /srv/jupyterhub/home/prod (a user named "prod").

- For the end users: I don't want the user to need to interact with JupyterHub because then the user has to 1) log into JupyterHub, and 2) Spawn a server, and 3) then apply the `babeurl/apps/foo.ipynb` link in their browser. This is too clunky for a non-technical user. So for prod, I spin up a single user server (docker run --detach --name appmodesrv --restart always -v /srv/jupyterhub/home/prod:/tmp/working -w=/tmp/working -p 8888:8888 -it mysingleuserserver jupyter notebook --no-browser --allow-root --ip="0.0.0.0" --notebook-dir=/tmp/working --NotebookApp.token=''"). Then the users just point to mydomain:8888:/app/MyApp1.ipynb. All good! 

On Wed, Apr 17, 2019 at 11:05 AM Chris Holdgraf <chol...@gmail.com> wrote:

Check out Voila! ( https://github.com/QuantStack/voila)  I bet that you'd find it interesting - it's quite similar to app mode :-)

On Wed, Apr 17, 2019 at 6:54 AM Alexander Feiszli <alex....@gmail.com> wrote:

Hello, 

At my org we are looking to implement Jupyter notebooks in production as sort of "mini-apps" for small groups of end users. The idea is that the data scientists can develop in Jupyterhub like an IDE and then push a notebook into a CICD workflow, and then out pops a production version that is accessible by a particular group of users. The reason for this is that the data scientists are not app developers, they do not want to write webapps, just work on their algorithms, and their end users are very small groups, maybe 6-12 internal users, so it is unnecessary to have a development team devoted to making nice looking apps for every algorithm they write. We just need a mechanism by which the end user can provide input data, it gets transformed by the notebook, generates some charts/graphs, and then they receive transformed output data.

For the end users, they should not be able to modify or create new notebooks, simply run a single notebook. For that reason we are looking at the "appmode" plugin (https://github.com/oschuett/appmode). The next thing we would like to do is have the production URL redirect to the running "appmode" version of the notebook. In addition, the production notebook server should basically just have all the other endpoints shut off or restricted, so that only this single "appmode" page is accessible.

Can someone point me in the right direction for how I could modify a notebook server to have requests to the base url redirect to this appmode page, and how to restrict or turn off the other endpoints? I am a bit lost but guessing I will need to modify the handlers here: https://github.com/jupyter/notebook/blob/master/notebook/notebook/handlers.py

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jup...@googlegroups.com.

To post to this group, send email to jup...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/d290d0dd-151e-4af0-a59c-e3cd38f78ccf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jup...@googlegroups.com.