4 ms·
That's definitely controversial, and in my experience, just plain wrong. Many, many users sign up to a service with john.doe@example.com and get confused when t
by craigds 9y ago
That's definitely controversial, and in my experience, just plain wrong. Many, many users sign up to a service with john.doe@example.com and get confused when they later try to log in with John.Doe@example.com. we had to add a fix for this in our django user model a couple years back. We havent had any complaints with the new, case insensitive system. IMHO this sort of this should be upstreamed but it seems Django have decided to stick with the spec in spite of usability.
- craigds 9y agoOh also, we used a CITEXT field for storing email addresses. Store the case the user registers with, and use that for sending comms etc, but uniquify and match (on login etc) in a case insensitive way.
- chatmasta 9y agoThis is an especially common problem when entering email addresses on mobile. Often autocorrect will capitalize the first letter. I always make sure it’s lowercase when registering, but I can see how this could easily lead to confusion.
- lsaferite 9y agoWeb pages (and apps) that don't indicate the input box is actually an email address so auto-correct won't capitalize for you are a serious peev of mine.
- pluma 9y agoI ran into this problem as well and in the end added a separate field for the normalized (lowercase) form with a uniqueness check on that. Users would still be presented the original case and it would be preserved when sending e-mails but for identification/uniqueness purposes e-mails were considered case insensitive.
- papito 9y agoRight, something like "email_lc", and "username_lc". This would be your unique index.
- jcranmer 9y agoAs you clarify later, both case-sensitive and case-insensitive are wrong. What you generally want is case-preserving: store the original case, but allow case-insensitive matches to select it.