Logged in user not getting default scopes

JupyterHub
, ,
1

The primary issue is that the logged in user is unable to see launch progress and unable to delete their own server. As such scopes seem to be off.

The jupyterhub is launched using a helm chart (version: 2.0.1-0.dev.git.6012.h458d566c helm call). Here is the templated helm config. The hub itself is running on AWS with an elastic load balancer, and i point to it through a CNAME mapping from my DNS provider. We deploy our own k8s cluster (not through EKS).

The user is dynamically authenticated through Github and authorized through a json file. I have also done org-based authorization without overriding the authenticator, and the same issue holds. I am also seeing the CORS issue that has been discussed on this forum, but i am unsure how to fix that in our setup. We are not running an nginx, just a classic load balancer deployed by the helm chart.

Blocking Cross Origin API request. 
Referer: https://kbhub.cirrusscience.org/hub/spawn-pending/satra, 
Host: kbhub.cirrusscience.org, 
Host URL: http://kbhub.cirrusscience.org/hub/

Since this is on AWS, we are using an ARN certificate associated with the domain. at least in this issue switching to lets encrypt helped, but i don’t understand why: Cross-origin and authorization errors after Z2JH 1.2.0 -> 2.0.0 upgrade

Update: I can confirm that using lets encrypt solves this issue. however, we cannot switch to that mode easily, so the standard aws load balancer offloading is still going to be relevant to us.

2

The CORS problem (mismatch between http and https) is the root problem. This means your user isn’t authenticated, and therefore doesn’t have the needed scopes.

You’ll need to look into your load-balancer configuration to find out how to set the correct headers so JupyterHub knows https is used.

3

thanks @manics. isn’t the load-balancer configuration + https offloading happening with helm chart ? by switching the https to use letsencrypt, instead of the aws certificate, the problem resolves. hence, perhaps something in the helm chart for jupyterhub, in relation to aws that needs to be adjusted.

4

It depends how you’ve configured everything. If you’re terminating HTTPS at the load balancer then you need to look at your load-balancer annotations to set some forwarded headers.

5

i was just following this: Security — Zero to JupyterHub with Kubernetes documentation and i found this: Annotations - AWS Load Balancer Controller . however, i really don’t know what to set there, any ideas?

6

Unfortunately I don’t have an answer, there’s a long discussion about some of the problems in https://github.com/jupyterhub/zero-to-jupyterhub-k8s/pull/1811

The good news is in JupyterHub 4.0 the CORS detection is improved, so if you’ve already got a deployment working with Lets Encrypt the easiest option is to stay with that for now.