Some help ref which token to pass for accessing Notebook API running inside JuptyerHub/JupyterLab

[Analect]

I'm running v 5.0.0-dev of the notebook with v 0.9.1 of JupyterLab, which is running with v. 0.7b1 of JupyterHub and deployed using this jupyterhub-deploy-docker approach.

I can access / interact with the JupyterHub API fine using the token I set in jupyterhub_config.py

# Tokens for API
c.JupyterHub.api_tokens = {
    'testuser-token': 'testuser'
}

However, it's not clear to me if I should then be changing to use an alternative token to interact with the Notebook API, as suggested here.

This is from the logs of a new user server for 'testuser':

[W 2016-11-30 10:21:12.685 testuser configurable:168] Config option `open_browser` not recognized by `SingleUserNotebookApp`.  Did you mean `browser`?
[I 2016-11-30 10:21:12.694 testuser notebookapp:157] It looks like you're running the notebook from source.
    If you're working on the Javascript of the notebook, try running
    
        npm run build:watch
    
    in another terminal window to have the system incrementally
    watch and build the notebook's JavaScript for you, as you make changes.
    
[I 2016-11-30 10:21:12.703 testuser notebookapp:568] Writing notebook server cookie secret to /home/jovyan/.local/share/jupyter/runtime/notebook_cookie_secret
[I 2016-11-30 10:21:13.429 testuser __init__:153] JupyterLab alpha preview extension loaded from /opt/conda/lib/python3.5/site-packages/jupyterlab
[I 2016-11-30 10:21:13.436 testuser notebookapp:1295] Serving notebooks from local directory: /home/jovyan/work
[I 2016-11-30 10:21:13.436 testuser notebookapp:1295] 0 active kernels 
[I 2016-11-30 10:21:13.437 testuser notebookapp:1295] The Jupyter Notebook is running at: http://0.0.0.0:8888/user/testuser/?token=e6a13fb0b342a6d376eee15fa7cbca402527029a092dac7c
[I 2016-11-30 10:21:13.437 testuser notebookapp:1296] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).

Should I be using this 'long' token for interactions with the Notebook API? like Authoritization: token e6a13fb0b342a6d376eee15fa7cbca402527029a092dac7c

I haven't been able to get that to work. I was using a gitlabAuthenticator without problems, but it seems this is presenting itself in the returned body of the API call ...

I notice in the logs of the spawned server this:

[W 2016-11-30 12:21:26.879 testuser handlers:299] Blocking Cross Origin API request.  Origin: chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop, Host: jupyterhub.xxxxxx.com

should I be including some c.NotebookApp.allow_origin = '*' setting in the jupyterhub_config.py file?

And finally, in the Notebook API contents endpoint, do I need to explicitly enter the '{path}' as user/jovyan/work ... or is only required for files/folders from that base address ...

Thanks.

[jtyberg]

So basically, you're trying to access the API of individual notebook servers through JupyterHub, which is authenticating users via Gitlab.

I'm going to have to defer to @minrk on this one.

[Analect]

@jtyberg yes. The gitlab authentication is akin to the default github one, where I'm also supplying a userlist specifying whether a user has hub admin rights.

For context, as per issue 25, I'm looking to build in some flexibility in terms of what image is used to spin up a server. I would then like to be able to programmatically access (via the Notebook API), a user's given server.

Perhaps this belongs in a separate issue ... but your usage of docker volumes to persist data between different instances of a users' server is novel. I was wondering if you explored a way of pre-seeding these with just the source code from a repo .. which could then be pushed back with git to a VCS ... so a user has benefit of persistence, but also version-control.

[minrk]

JupyterHub replaces the authentication mechanism, so the token-auth introduced in notebook master won't work (yet) with JupyterHub. I'll work on that after we push out the 0.7 release (likely tomorrow).

[Analect]

OK. Thanks @minrk for clarifying. Happy to test as and when you get time to implement.

[jtyberg]

Thanks, @minrk.

@Analect regarding pre-seeding the Docker volumes with git repos, there's an example of using a custom entry point script here to clone a git repo at container startup. Pushing back to the git repo will require the notebook user is authorized to do so. I've not tried this.

[Analect]

@jtyberg Thanks for that pointer. Rather than requiring all users to have knowledge of git ... in order to push some/all changes back to the repo via a terminal, for instance, perhaps some variant of this gist extension from @minrk could present a user with a dialogue box from within jupyterlab for a user to add a commit msg and then push any changed file(s) collectively.

[jtyberg]

@Analect Agree with passing the git auth responsibility to the user. Either they enter creds or upload an SSH key.