This default change (only relevant if lookup_dn=True) makes JupyterHub usernames end up what was entered into the login form, as compared to end up what was looked up from a found user's value of the attribute which name was configured via use_lookup_dn_username.
In practice, this can be the difference between getting JupyterHub usernames like philip j. fry (normalized from Philips J. Fry) and fry when entering the username fry when logging in.
I propose this breaking change because:
I think its more intuitive behavior to have users with the username they write when logging in
It would make toggling between using bind_dn_template to lookup_dn configs less likely to change existing jupyterhub users' usernames.
I think its less risky from a security perspective, as the usernames provided in the login form are checked to be lowercase for example, and that means jupyterhub's normalization of usernames wont change much later, which means that a single username given in the login form becomes guaranteed unique no matter if LDAP is case sensitive or not etc. We want to avoid multiple users get overlapping jupyterhub account names, as possibly could happen after normalization of something picked via a lookup based on the login forms username.
Overall, I'm not sure if there is a security risk or not related to this, but since I've not ruled it out I figure this is the safer default.
This default change (only relevant if
lookup_dn=True
) makes JupyterHub usernames end up what was entered into the login form, as compared to end up what was looked up from a found user's value of the attribute which name was configured viause_lookup_dn_username
.In practice, this can be the difference between getting JupyterHub usernames like
philip j. fry
(normalized fromPhilips J. Fry
) andfry
when entering the usernamefry
when logging in.I propose this breaking change because:
bind_dn_template
tolookup_dn
configs less likely to change existing jupyterhub users' usernames.