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
(This is related to an issue posted in the Oauthenticator repo as well).
In our setup, we have a deployed multiuser system, where user accounts are created by ansible from membership within a GitHub team. We don't have any say over our user's GitHub usernames, but being that it is GitHub, they are all valid POSIX usernames. We're running a Jupyterhub instance (through Docker) where we are using Github Oauth for authentication, and the System User Spawner from the Docker Spawner to have the users' home space be mounted within the raised docker container.
For users with usernames only using lowercase characters, everything works as expected. However, if a user has a mixed case username, the spawner fails since the username passed on by the authenticator (where we override the normalization of the username) gets escaped, and no home directory is found for the sanitized username. At the moment, we are using the c.DockerSpawner.escape = "legacy" option as a workaround, but this isn't optimal from a security standpoint.
At least in some cases (such as jupyterhub/oauthenticator#168) the username provided by the authenticator will be mixed case. Can the behaviour of the default escape method be to accept mixed case usernames?
Thanks kindly!
Your personal set up
We are using the JupyterHub docker container (v4.0.1) on a multiuser Ubuntu host VM.
Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.
You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋
Can the behaviour of the default escape method be to accept mixed case usernames?
I don't think so, since mixed-case definitely can cause problems in various places, but we could consider it with sufficient testing.
But if you know that usernames are always safe in your particular deployment, you can use {raw_username} in your templates to avoid any escaping instead of {username}. I'm assuming it's your volume mounts that are the issue, so using {raw_username} in your host_homedir_format_string and image_homedir_format_string config ought to get things working.
Bug description
(This is related to an issue posted in the Oauthenticator repo as well).
In our setup, we have a deployed multiuser system, where user accounts are created by ansible from membership within a GitHub team. We don't have any say over our user's GitHub usernames, but being that it is GitHub, they are all valid POSIX usernames. We're running a Jupyterhub instance (through Docker) where we are using Github Oauth for authentication, and the System User Spawner from the Docker Spawner to have the users' home space be mounted within the raised docker container.
For users with usernames only using lowercase characters, everything works as expected. However, if a user has a mixed case username, the spawner fails since the username passed on by the authenticator (where we override the normalization of the username) gets escaped, and no home directory is found for the sanitized username. At the moment, we are using the
c.DockerSpawner.escape = "legacy"
option as a workaround, but this isn't optimal from a security standpoint.At least in some cases (such as jupyterhub/oauthenticator#168) the username provided by the authenticator will be mixed case. Can the behaviour of the default escape method be to accept mixed case usernames?
Thanks kindly!
Your personal set up
We are using the JupyterHub docker container (v4.0.1) on a multiuser Ubuntu host VM.
OS:
Ubuntu 20.04
Version(s):
JupyterHub: 4.0.1
Oauthenticator: 16.0.1
Dockerspawner: 12.1.0
The text was updated successfully, but these errors were encountered: