You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the dask-gateway client is reading the user's JUPYTERHUB_API_TOKEN, which then is passed to the dask-gateway-server, which then confirms the jupyterhub api token is associated with a real user via the hub/api/authorizations/token api by using the user's api token.
Drawbacks
dask-gateway clients sends away the user's api token and its used directly - its a course authentication check that gets the full permission of the user (I think) even though dask-gateway server just needed to confirm the user was allowed
there isn't a mechanism to provide some users but not all users access to work with dask-gateway if what dask-gateway-server only checks if the user exists or not
Alternatives
In this jupyterhub documentation I understand that there is a way to implement authentication that ens up requiring the user to have access:services!service=$service-name where service name could be dask-gateway for example (it should be the service name configured with jupyterhub, allowing dask-gateway to interact with jupyterhub in the first place).
Action points
Consider if its reasonable to migrate the existing authentication check to something new that requires users to have a scope of access:services!service=$service-name.
The text was updated successfully, but these errors were encountered:
Currently the
dask-gateway
client is reading the user'sJUPYTERHUB_API_TOKEN
, which then is passed to thedask-gateway-server
, which then confirms the jupyterhub api token is associated with a real user via thehub/api/authorizations/token
api by using the user's api token.Drawbacks
Alternatives
In this jupyterhub documentation I understand that there is a way to implement authentication that ens up requiring the user to have
access:services!service=$service-name
where service name could bedask-gateway
for example (it should be the service name configured with jupyterhub, allowing dask-gateway to interact with jupyterhub in the first place).Action points
Consider if its reasonable to migrate the existing authentication check to something new that requires users to have a scope of
access:services!service=$service-name
.The text was updated successfully, but these errors were encountered: