Usernames having an upper-case character fail to authenticate.

[jbittel]

Usernames having an upper-case character fail to authenticate.

[jbittel]

Good catch! I've mostly been testing against the django-auth-ldap backend which does case insensitive lookups and creates new usernames as lowercase, and caused me to gloss over this whole issue. I've pushed up 4c80af5 which removes all of the lower() calls on username. That should resolve the immediate issue you noted.

Regarding the bigger question, I'm wondering if it should simply be left up to the authentication backend(s) in use to determine whether or not usernames should be case sensitive. There could be a setting within mama-cas that allows for modification of the username, but that wouldn't change how a backend handles the lookup and could create surprises. The downside is that if multiple backends are in use, it's very possible they could implement it differently (e.g. django-auth-ldap and the model backend). At least in that example, the model backend would be easy to replace with a case-insensitive version.

Any additional thoughts? I'm not sure if there are additional use cases I'm not thinking about.

[bryankaplan]

1. I sign up as "Bryan".
2. My username is saved as "bryan".
3. I fail to log in as "Bryan".

∴ The frontend must agree with whatever scheme the backend uses.

[jbittel]

Are you testing against the latest commit that removed the lower() calls? I've checked it against both a case-sensitive and case-insensitive authentication backend, and it now works as expected in my tests.

My point above was that mama-cas does not directly create or authenticate a user, but relies on other apps or backends for those tasks. However the user creation process happens it will certainly need to agree with the active backends, but currently that should all be external to mama-cas.

[bryankaplan]

Please forgive my delay in reply. I've been swamped.

I haven't tested this with HEAD, but I can. Back when I opened this issue, I modified my registration script to lower() all usernames. I opened this issue anyway, just in case other people run into the problem.

I did have a look at 4c80af5, and honestly I'm not sure how it would work with any case-insensitive backend.

Please explain how the workflow outlined in my previous comment can succeed if mama-cas does not lower(). I signed up as "Bryan" but I can not sign in as "Bryan". Right?

[jbittel]

Sure, no problem. Here's the basic process:

1. You sign up as "Bryan". This process is external to mama-cas and could happen in different ways, but the result is a User created in auth_user. For this example, the username is exactly "Bryan" (mixed case).
2. You log in using mama-cas, entering your username in the form field as "bryan". Within the clean() method of LoginForm the unaltered form data is passed to the authenticate() method of the currently configured authentication backend. For a simplistic example, here is a case-insensitive authentication backend. This backend takes the username string (still a lowercase "bryan") and does an iexact query for a matching User. The username "Bryan" matches and the User is returned to mama-cas.
3. That User is then passed to the login() method within LoginView to log the user in successfully.

If the backend is not case-sensitive, in step 2 you could have logged in as "Bryan", "BRYAN" or "bryan" and all of them would be successful.

The authentication backend makes the determination as to how User lookups are handled externally to mama-cas. The above example backend could be trivially converted to case-sensitive by changing the query to exact. The problem that you correctly pointed out was that mama-cas was originally fiddling with the username string, which could cause problems if a case-sensitive backend was in use.

Does that help explain things better?

[bryankaplan]

Yep. Thanks very much for the detailed explanation. It makes good sense.