During some recent testing, we discovered that usernames in our users table are case-sensitive while usernames in LDAP appear to be case-insensitive. We are currently saving the username as it is typed by the user while logging in rather than the username that comes back from the auth service.
As a result, on a venue with LDAP authentication enabled, I can login as either delany or DELANY and either of these will work - however, this will create two different users in the Aerie database that are both associated with the same LDAP user.
Per discussion in Slack, the response from the LDAP/other auth server should contain a "canonical" version of the username, and this is the version we should store in our database, rather than the exact input provided by the user. Of course in environments with no authentication enabled, this is not possible and we should fallback to saving the user's input.
Checked for duplicates
Yes - I've already checked
Is this a regression?
No - This is a new bug
Version
2.7.0
Describe the bug
During some recent testing, we discovered that usernames in our users table are case-sensitive while usernames in LDAP appear to be case-insensitive. We are currently saving the username as it is typed by the user while logging in rather than the username that comes back from the auth service.
As a result, on a venue with LDAP authentication enabled, I can login as either
delanyorDELANYand either of these will work - however, this will create two different users in the Aerie database that are both associated with the same LDAP user.Per discussion in Slack, the response from the LDAP/other auth server should contain a "canonical" version of the username, and this is the version we should store in our database, rather than the exact input provided by the user. Of course in environments with no authentication enabled, this is not possible and we should fallback to saving the user's input.
Reproduction
Severity
Minor