Revoking shared access for a single user is only effective after server restart

Hey there,

Probably I’m missing something, but it seems like that revoking shared access for a single user is not directly effective. I was still able to access the shared server. After I restarted the server, I was no longer able to access it.

However, revoking all shared access works fine, and trying to reload the page results in a 403.

I did some debugging and captured some logs. Revoking shared access for a single user via PATCH /shares/{owner}/ with the following body resulted in the response 200 {}. According to the documentation, this states that all permissions for the given user have been removed.

{
  "user": "testuser",
  "scopes": []
}

Also, the logs state that

[I 2025-06-13 14:19:21.901 JupyterHub orm:897] Revoked all permissions from user:testuser on owner/

In addition, revoking all shared access after revoking the access for the only added user results in

[I 2025-06-13 14:40:53.486 JupyterHub shares:447] Deleting all shares for owner/
[I 2025-06-13 14:40:53.487 JupyterHub shares:452] Deleted 0 shares for owner/

So it looks like the permission was removed. However, I’m still able to access the server if I’m only revoking the access for a single user.
Revoking all shared access via DELTE /share/{owner}/ results in the following error for the user as expected.

Does somebody have a clue what I’m missing?

Sorry for the confusion. I tried it again, and both methods (single revocation and revoking all shared access) led to the same result: I am still able to access the running server.

Is it intended to stop/restart the server in order to apply the revocation?

JupyterHub uses OAuth to authenticate singleuser servers with the hub. This is independent of the Authenticator you use to login to JupyterHub:

You can try reducing JupyterHub.oauth_token_expires_in to force the singleuser server to refresh the token sooner, and therefore check whether the permissions have changed.

1 Like