Regular users get 502 Bad Gateway when accessing JL server, Admin users can access just fine

JupyterHub
1

We’re setting up jupyterhub for several users in our org. We only want to have a few admin users, but we’re having trouble figuring out how to let regular users access their servers.

Below what I assume is the relevant part of the config file that our devops team set up for us.

apiVersion: v1
data:
  config.yaml: |
    hub:
      baseUrl: /202tpe01mo/jupyter
      loadRoles:
        user:
          scopes:
          - read:tokens!user      # devops put this here
          - users:activity        # I have added this
          - access:servers!user   # I have added this
          - servers!user          # I have added this
      services:

Initially, regular users could not even start or stop their servers, I’ve added user permissions to help with that. Regular users can now start and stop their servers, but when they try to go to their server URL to access it they get a 502 bad gateway issue. I assume there are other permissions we need to add but have been having a tough time sifting through all of it.

2

502 should not be able to be directly caused by permissions. Can you share logs from the Hub and proxy when this happens? Maybe it’s indicative of failure to start for one reason or another, which could be caused by permissions.

By overriding the user role, you are redefining what users can do, starting from no permissions at all. The default scope for user is self, which includes a lot of things with the !user filter. Perhaps what is missing here is read:users!user. What you have here is significantly less than that. Is that your goal, to restrict default user permissions below the default? Or do you only want to expand default user permissions? The only expansion you have is unfiltered users:activity, meaning all users can register activity for all other users (perhaps not intended?).

If you want to add permissions for the default user role, include self in the list. But if you do that, none of the permissions you have here are additions (assuming you put !user on activity).

3

Thanks for the reply. Adding read:users!user did fix the issue for us.

And thanks for the heads up on users:activity, I’ll take a look at that to see if we really want it.