Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support authentication #666

Merged
merged 18 commits into from
Oct 11, 2018
Merged

support authentication #666

merged 18 commits into from
Oct 11, 2018

Conversation

bitnik
Copy link
Collaborator

@bitnik bitnik commented Sep 18, 2018

Clean version of #596.

From #596:

Mainly I think the separate use_oauth config is unnecessary, since auth_enabled seems to never be true without it.

It seems we don't nee to have separate auth_enabled and use_oauth flags. We can have a single auth_enabled flag that sets up HubOAuth, perhaps? Or even run with a jupyterhub_service flag that will load the full service config (URL, etc.)?

Maybe I don't understand what @minrk meant here. I still think that we need 2 flags: auth_enabled is to hold if authentication is enabled and use_oauth is to hold if an authenticator from https://github.com/jupyterhub/oauthenticator is used.

I would love to get some tests for the authenticated cases. Do you think you are up for that?

I started writing tests but I am not sure what I did is right.

There is already a problem while running auth tests locally. The problem is that HubAuth.api_token is not filled with JUPYTERHUB_API_TOKEN env variable by default (https://github.com/jupyterhub/jupyterhub/blob/master/jupyterhub/services/auth.py#L172). As a workaround I added the dynamic default value generator for api_token in jupyterhub/services/auth.py:

    @default('api_token')
    def _default_api_token(self):
        return os.getenv('JUPYTERHUB_API_TOKEN', '')

When I do this, tests work locally. Is this a bug in JupyterHub or is the way I did auth tests wrong?

cfg.BinderHub.use_oauth = False
cfg.BinderHub.use_named_servers = False

os.environ['JUPYTERHUB_API_TOKEN'] = cfg.BinderHub.hub_api_token
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the class has been imported already, setting the environment variable here is too late. Instead, we can set cfg.HubAuthenticated.api_token = cfg.BinderHub.hub_api_token directly. Same, I imagine, for the other environment variables. Set config values directly instead of relying on environment variables.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you mean cfg.HubOAuth.api_token = cfg.BinderHub.hub_api_token instead of cfg.HubAuthenticated.api_token = cfg.BinderHub.hub_api_token?

But still I don't understand how this is going to configure HubOAuth. This configuration in tests is only used here to create a bhub instance.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think reading https://traitlets.readthedocs.io/en/latest/config.html will help me to figure out how to do this

@minrk
Copy link
Member

minrk commented Sep 21, 2018

I still think that we need 2 flags: auth_enabled is to hold if authentication is enabled and use_oauth is to hold if an authenticator from https://github.com/jupyterhub/oauthenticator is used.

I don't think so. The switch here doesn't seem to be related to jupyterhub's own authenticator choice. use_oauth selects between the old HubAuthenticated (relies on cookies, fragile and inflexible) and the newer HubOAuthenticated (uses oauth to authorize with the Hub). I was recommending that we eliminate the use_oauth flag and always authenticate with the Hub via HubOAuthenticated.

)
body = json.loads(resp.body.decode('utf-8'))
return body

def username_from_repo(self, repo_url):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe rename it to unique_name_from_repo now that it generates more than just a username.

username, e, body,
)
raise web.HTTPError(500, "Failed to create temporary user for %s" % image)
elif server_name == '':
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

elif server_name == '': -> elif server_name: should be enough to check if a string is not empty.

@bitnik
Copy link
Collaborator Author

bitnik commented Sep 25, 2018

@minrk @betatim thanks a lot for reviews!

@minrk sorry, you were right, I was thinking wrong about HubOAuthenticated and HubAuthenticated. I changed it to use only auth_enabled flag and authenticate with JupyterHub through HubOAuthenticated.

@bitnik bitnik force-pushed the authnew branch 2 times, most recently from 03c321f to 7004ada Compare September 26, 2018 14:27
@bitnik
Copy link
Collaborator Author

bitnik commented Sep 27, 2018

hmm I don't understand why test_auth fails on travis. It gets 404 for http://10.20.0.132:30123/services/binder/. But locally I don't have this error. Do you have any idea why this is happening?

Btw I did all changes that you requested.

hub:
services:
binder:
url: http://10.0.2.2:8585
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This hardcoded ip may not be stable for any given deployment

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true, this IP is only for when VirtualBox driver is used

only when VirtualBox drive is used.
minikube runs on travis without VM driver.
try to get and use host IP.
@bitnik
Copy link
Collaborator Author

bitnik commented Oct 9, 2018

@minrk tests passed after I replaced 10.0.2.2 with host IP.

@minrk minrk merged commit b56f85b into jupyterhub:master Oct 11, 2018
@minrk
Copy link
Member

minrk commented Oct 11, 2018

Awesome, thanks!

@choldgraf
Copy link
Member

boom! this one has been a long time coming! really nice @bitnik :-)

@bitnik
Copy link
Collaborator Author

bitnik commented Oct 12, 2018

finally :) thanks to all of you!

@meeseeksmachine
Copy link

This pull request has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/a-persistent-binderhub-deployment/2865/1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants