Usernames should be case insensitive

[Jason Boyer]

Eg 3.0.3

Evergreen is the only online system (that people will willingly use...) that I'm aware of that forces case sensitive usernames. I know there may be some (minor) pain when correcting this if there are already overlapping usernames but I don't see any reason to perpetuate this, especially in new installations.

[Jeff Godin (jgodin)]

+1

Anticipating that deprecation and phase-out may require some time and some local decision making, a useful early step may be to begin folding new username values to lowercase and prevent setting any username values that would be non-unique if existing usernames were likewise folded to lowercase.

Now would also be the time to determine if there are other restrictions we'd like to place on username values.

Worth mentioning here because they often appear in the same input field: barcodes may need to remain case sensitive.

Are there any known LDAP / auth proxy environments where supporting case-sensitive or case-preserving usernames is important?

[Jason Boyer (jboyer)]

I suppose it may be worth creating an OUS for forbidden characters (initially populated with []{}();:\/ at least) so that installations can be more or less strict without code changes. Personally I'd be happy to hard code that list and allow others to be added but I'm open to ideas.

[Jason Stephenson (jstephenson)]

Here's a little something that you can run to see if you have user names in the database that differ only in case. We have a few hundred such duplicates, though a handful look like duplicate patrons who used the same user name, once in uppercase and once in lowercase.

select a.id, a.usrname, b.id, b.usrname
from actor.usr a
join actor.usr b
on lower(b.usrname) = lower(a.usrname)
and b.id > a.id
and not a.deleted and not b.deleted;

[Josh Stompro (u-launchpad-stompro-org)]

+1 , found no conflicting usernames in our DB currently. I think this should be the default without it being optional.

I like the idea of there being forbidden characters.

Josh

[Jason Stephenson (jstephenson)]

Barcodes have a similar problem:

select a.id, a.usr, a.barcode, b.id, b.usr, b.barcode
from actor.card a
join actor.card b
on lower(b.barcode) = lower(a.barcode)
and b.id > a.id
and b.usr <> a.usr
and a.active and b.active;

The above finds a couple of duplicates on our system that might be tied to duplicate or even deleted user accounts. I didn't push it that far, but checking for active barcodes should throw out deleted users.