Add instructions on using own client id

[KesterTong]

Currently, the hardcoded client id is configured to only accept origins 127.0.0.1:8888, 127.0.0.1:8889, ..., 127.0.0.1:8899. It is not possible (or advisable) to allow all origins, or even all ports. For most users this just means that they need to be aware of the limitation that they must user ports in this range.

If a user wants to run their own server from a different domain, they will have to create their own cloud console project and modify the client id.

If there is demand for this, we should add documentation and possibly the ability to set the client id through configuration (though this should be done carefully wrt security).

[Carreau]

This one is hard. I've tried to understand @takluyver new config system client side, but the full usage is still complex for me. I've made a Pull request to IPython that should still allow to make this configurable.

[takluyver]

The JS config API:

ConfigSection loads data from the server and sends updated data. main.js will do something like this:

config = new configmod.ConfigSection('notebook'); 
config.load();  // Returns immediately, loading is asynchronous

For some uses of config, you can use the config object directly:

config.loaded.then(function() {
    IPython.load_extensions(config.data.load_extensions);  //config.data contains the data
});

For more complex uses, I added the ConfigWithDefaults class. This takes a config section, a dictionary of defaults, and optionally the name of a namespace within the config section:

this.class_config = new ConfigWithDefaultss(this.config, Notebook.options_defaults, 'Notebook');

Because config is loaded asynchronously, there are two possibilities when looking it up:

// Wait for the config to load (returns a promise)
this.class_config.get('some_key').then(...);

// If the config hasn't loaded yet, just use the defaults
val = this.class_config.get_sync('some_key');

Modifying config - both ways will modify local data immediately and send the change to the server asynchronously:

// On the ConfigSection
config.update({key: {subkey: value}}); // Can nest arbitrarily, will merge recursively
// On ConfigWithDefaults
class_config.set('key', value);

But note that this is all still provisional - we're just converting the first things to use it, and still working out what makes sense.

[Carreau]

Hum, I vaguely try something like that, but you have to set-up the base_url etc, which make it a bit painful. I'll retry.

[takluyver]

Sorry, yes, the first line of that example should have been more like this:

config = new configmod.ConfigSection('notebook', {base_url: base_url}); 

Since that should generally be created by main.js and passed in to other objects, that shouldn't be tricky, though.

[Carreau]

It's the "passed to other objects" that concerns me for extensions, but as you said it is provisional.

[takluyver]

Ah, I see. For extensions, I would just retrieve the base URL again with utils.get_body_data(). This is what I do in cite2c.

[rgbkrk]

What's the right way to lock down drive integration so that it only presents notebooks created with just the one client id?

[KesterTong]

I'm not sure how the client is configured, but once you set the client id, it will restrict you to access files created with that client id or another client id from the same cloud console project. We still display other files, but we have the ability to filter out the inaccessible files. On Feb 8, 2015 3:02 PM, "Kyle Kelley" [email protected] wrote:

What's the right way to lock down drive integration so that it only presents notebooks created with just the one client id?

— Reply to this email directly or view it on GitHub https://github.com/jupyter/jupyter-drive/issues/21#issuecomment-73428595 .

[KesterTong]

Another option we could add is a more locked down mode where we don't use the metadata.readonly scope, which is how we are able to view the directory tree, including files you don't have access to. Note that in this mode, you cannot even browse directories that weren't created by that cloud console project. Maybe this is a good thing On Feb 8, 2015 3:29 PM, "Kester Tong" [email protected] wrote:

I'm not sure how the client is configured, but once you set the client id, it will restrict you to access files created with that client id or another client id from the same cloud console project. We still display other files, but we have the ability to filter out the inaccessible files. On Feb 8, 2015 3:02 PM, "Kyle Kelley" [email protected] wrote:

What's the right way to lock down drive integration so that it only presents notebooks created with just the one client id?

— Reply to this email directly or view it on GitHub https://github.com/jupyter/jupyter-drive/issues/21#issuecomment-73428595 .

[rgbkrk]

Yeah, there was great demand after my talk at PyTennessee to add the ability to save and load notebooks straight to Google Drive when on tmpnb.org (or wherever).

[KesterTong]

@Carreau, what's the current status on configurability? Did that PR get merged?

@rgbkrk, there are two scopes we use, (see https://developers.google.com/drive/web/scopes), drive.file and drive.readonly.metadata. The latter grants readonly access to all metadata, which includes file names, and all people that all files are shared with. I think it's likely you don't want this scope with tmpnb. Removing it means you can't browse the full directory tree (since directories are just files). But you can create directories and files, and access any files/directories created.

[rgbkrk]

Ok, cool. When I set up another client I'll set just drive.file.

What are options for people to share notebooks/seed an installation?

Workflow would be that people show up to a workshop, authenticate with Google, and somehow get access to the course materials. /cc @dutc @willingc

[Carreau]

@Carreau, what's the current status on configurability? Did that PR get merged?

Yes, i'll have a look today, was in SF this week-end.

I think dropping metadata scope for tmpnb make sens,

[KesterTong]

Let's assume that we are only using drive.file scope and not drive.readonly.metadata scope.

The advantage is this is very restrictive. There is no way the app can access any file without explicit consent from the user. However, this can make it hard to add files to the files that the app can see. In particular, permission is always on a per user, per app (=cloud console project) basis. So it's not as simple as one user setting some files as viewable from the app, then sharing them. I'm going to do some experiments and see exactly what is possible.

@Carreau Thanks, looking forward to seeing the new config system.

[griffinmilsap]

I just got a message that referred me to this issue -- What further configuration do I need to do to get this running?

[KesterTong]

Hi @griffinmilsap, are you running IPython on your local machine, and if so, what port are you using? If you are running locally, you are probably best off changing to one of the ports that jupyter-drive is configured to work with (8888 to 8900 is the range I think). Otherwise, if you are setting up network access for other people, the instructions in the README now indicate how to set the client_id using our configurations system, but we aren't quite there when it comes to configuring the App ID, or providing instructions on how to create these (they are generated in the Google cloud console)

[griffinmilsap]

Hey @KesterTong, thanks for the quick reply! I'm running Jupyterhub on https://cerebro.neuro.jhu.edu which is spawning single-user notebooks for me. I believe these are spawning on port 443/444 or something, I'm not sure about all the details. I think I need to be on this port to operate using https. If I need to set up my own cloud console project, I'm okay doing that, but I don't know what APIs I need or how they should be configured..

[Carreau]

Yes, you will have to create an application/client-id yourself. and bind it to your domain.

I should get better information on how to do that.

There are still bugs for jupyterhub+jupyterdrive, though so be careful, You might have to dive in the configuration a little more than usual.

[griffinmilsap]

Wow! You guys are really on top of your issue tracker! Props! Let me know if/when/where there is information about how to configure this cloud console project, and I'll test it out/let you know how it works out. I'm not above digging down into the code and resolving errors as they pop up -- I might even be able to submit some PRs as needed.

[Carreau]

You should be able to create it in google console project now. After you will have to set it in ~/.ipython/profile_<name>/nbconfig/common.json

[Carreau]

Will edit this comment progressively (approximative, my system is in french) :

• go to https://console.developers.google.com/project
• new project.
• API and Auth -> activate Drive API
• Create ID
• Web ID
• Fill the authorized domains

[griffinmilsap]

That seems to have done the trick! I have it working well so far. Will update if I find any bugs. Thanks!

[janakmayer]

I am also trying to run a server on my own domain and on a custom port (though I could change to use the standard port if need be). I have created a project on the google developers console, activated Google Drive API, and created an oAuth Client ID for a Web App.

I didn't seem to have an nbconfig directory in ~/.ipython/profile_, so I created one and created common.json based on this example: https://github.com/jupyter/jupyter-drive/issues/85, putting in my own CLIENT_ID.

Having done that, when I start the notebook I get an "Unrecognized JSON config file version, assuming version 1" error, and although the notebook starts just fine, I suspect it may not have registered my config, since when I click on my gdrive folder, I still get the origin_mismatch error.

Any pointers would be very much appreciated!

[Xiaojing]

Hi @griffinmilsap, I saw your comment that you had Jupyterhub + Jupyterdrive working well. My colleagues and I are trying to do the same thing. But after we install and activate Jupyterdrive, we dont see the "gdrive" folder in user tree. We dont see the nbconfig directory in ~/.ipython/profile_. If you could share your setup and configuration details with us, we would greatly appreciate it. Thanks so much!

[griffinmilsap]

@Xiaojing It's been a bit over a year and I can't really remember everything I had to do to get it to work. For what its worth, I just followed the readme and the instructions in this thread and I got everything working properly. I don't know what the status of the project is today and if any recent updates to Jupyter have broken the configuration...

[Xiaojing]

Hi @griffinmilsap Thank you so much for your quick response! We followed the instruction in readme, but couldn't find some the configuration files that are supposed to be automatically created according to the instruction. Did you deploy your Jupyterhub environment using this jupyterhub/jupyterhub Docker image? We used that in our environment.

Hi @Carreau Are there any updates on the Jupyterhub + Jupyterdrive work? Thanks a lot.

[cloutiertyler]

@Xiaojing, did you end up having any luck with this?

[ian-r-rose]

Hi @cloutiertyler , work on this project is continuing at https://github.com/jupyterlab/jupyterlab-google-drive. It is still a work in progress, but there are some instructions there for setting up your own client ID.