Problem/Motivation
Drupal usernames are case-insensitive, but CAS's username matching is case sensitive. When a user with a Drupal username / CAS ID "SOMEONE" tries to log in, but the CAS server returns a CAS ID of "someone", the CAS module returns an error stating that the user cannot be registered because a user with that username already exists.
This issue has been reported to the externalauth module, where it was determined that this needs to be handled within the CAS module: https://git.drupalcode.org/project/externalauth/-/work_items?show=eyJpaW...
Steps to reproduce
Take a user that can log in successfully with CAS, and introduce a case-sensitive change to their username / CAS ID. For instance, change "someone" to "SOMEONE". Make sure that user is logged out, then attempt to log in as that user. You will get a message saying that the user could not be registered because a user with this name already exists.
Proposed resolution
Downcase the ID returned from CAS, and then downcase the Drupal user's stored CAS ID to ensure a case-insensitive match.
Remaining tasks
Add downcasting to user matching process.
User interface changes
Perhaps add a configuration boolean allow enabling/disabling of case sensitive matching.
API changes
Unknown.
Data model changes
Unknown.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | externalauth_case_sensitivity_3.patch | 1007 bytes | francismak |
Comments
Comment #2
roderik...after upgrading the externalauth module to >= 2.0.13. (The security update == the behavior change. Which implies CAS wasn't insecure, but other systems potentially were, and CAS is now suffering from the fallout... when upgrading to externalauth 2.0.13.)
Comment #3
bkosborneNot really sure how to handle this. I don't think we can safely just downcase the Drupal and CAS usernames safely for everyone using this module. Case sensitivity might not matter in your CAS setup, but it might in others.
Comment #4
francismak commentedFor our case, we have legacy users with mixed cases in their username.
Temporary workaround patched for externalauth, v2.0.13, sorry if this is not appropriate to upload non CAS patch here.
The update function from externalauth changed the db column to binary safe.