Opened 18 years ago

Closed 11 years ago

Last modified 7 years ago

#2273 closed Cleanup/optimization (wontfix)

django.contrib.auth.models.User: username is case-sensitive

Reported by: mderk@… Owned by: Adrian Holovaty
Component: contrib.auth Version:
Severity: normal Keywords:
Cc: Danilo Bargen, cmawebsite@…, Info-Screen@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


The User.username is now case-sensitive, that makes possible registering and logging in several different users with the same username in different case mix. That can make a lot of confusion and serious implication (e.g. it's impossible to give a user a subdomain username.domain.tld in a safe way)
In general, the use case for usernames implies that username is case-insensitive, or at least is unique in lowercase. I think that there should be at least a configuration parameter to treat usernames in several modes - case-insensitive, lowercase-unique, lowercase-only, or case-sensitive (current, compatibility) mode.

Change History (19)

comment:1 by Adrian Holovaty, 18 years ago

Resolution: wontfix
Status: newclosed

This backwards-incompatible change isn't worth making, but you can use your own authentication backend if you need case-insensitive usernames. Check out .

comment:2 by paul@…, 17 years ago

Resolution: wontfix
Severity: majornormal
Status: closedreopened

The standard behaviour for most web apps is to treat user names case insensitively. So I think that Django just gets this wrong.

The original bug report suggested how to fix this in a backwards compatible fashion. There should be a setting that turns off the backwards-compatible behaviour in favour of the more standard (and usable) behaviour.

You have the right to set this as wontfix, but the justification should be more sound. (even if its: "we just don't have time")

comment:3 by Adrian Holovaty, 17 years ago

Resolution: wontfix
Status: reopenedclosed

We just don't have time.

comment:4 by Farhan Ahmad, 15 years ago

I have posted a quick tutorial on how you can create a new authentication backend that supports case-insensitive username lookup. Check it out if you trying to accomplish this:

comment:5 by anonymous, 12 years ago

Easy pickings: unset
UI/UX: unset

as noted in the comments of the blogpost linked by thebitguru, adding a custom authentication backend does not solve all of the problems that this bit of non-standardness creates . . . hopefully someone will pick this up and address it in the future. Just another thing that makes django a PITA sometimes and increases support calls for me.

comment:6 by Danilo Bargen, 12 years ago

Cc: Danilo Bargen added

comment:7 by tsal@…, 11 years ago

Resolution: wontfix
Status: closedreopened

At least fix this with the default user model in 1.5 and above. This is literally the only framework I can easily find that has case-sensitive usernames. No, that doesn't mean this is the correct path, but doing things so counter-intuitively in python makes my head hurt.

Adrian - if you don't have time, at least keep this open for someone else to submit a patch - I'm certain one of us can put together something.

It's quite annoying to have to use a custom authentication backend for something so dead simple in concept - this should be part of Django.

comment:8 by Russell Keith-Magee, 11 years ago

Resolution: wontfix
Status: reopenedclosed

No, we're *not* going to make this change. 4 years ago, it may have been a time thing, but now, we're dealing with backwards incompatibility. Making this "trivial" change would have a massive impact on existing deployed code. We're not going to violate backwards compatiibility when there is a backwards compatible option available.

comment:9 by anonymous, 11 years ago

WIth all due respect, its not a trivial change. Its a very, very common probably when running a consumer facing site.

As the original ticket stated, this could be a config (still would be backwards compatible). Its not a heavy or time-consuming change.

comment:10 by bryce2@…, 10 years ago

So what's wrong with making the change, by default applicable only to new sites?

comment:11 by Russell Keith-Magee, 10 years ago

@bryce -- because the migration path isn't trivial either. We'd be implementing a feature flag, and then we'd need to support the feature flag, and support queries from users confused over the introduction of the new feature... all to support something that can be achieved right now if you want that particular feature.

comment:12 by mkhalil28@…, 10 years ago

in django/contrib/auth/

change the get_by_natural to the following:

def get_by_natural_key(self, username):
    return self.get(username__iexact = username)

and your all set :)

comment:13 by Carlos Killpack <carlos.killpack@…>, 10 years ago

Whose idea was it to make usernames case-sensitive in the first place? I suppose nothing can be done at this point, but y'all probably should have thought about it a bit more before committing yourselves to it for so long. It was a stupid decision.

Think about a user logging into a Django-powered site, do you think she gives a shit about which letters she capitalized when she filled out the registration form? I doubt it. Why even make her remember? Capitalization isn't that important!

comment:14 by Oliver Ewert, 10 years ago

This is clearly a sore point for some people judging by my googling. I understand that the change would have been hard 8 years ago and is now near impossible.

Shouldn't there at least be a note added to the documentation, I currently see nothing about this in the documentation (maybe I missed it?)?

Simply adding "Note: usernames are case sensitive" to would be a step in the right direction.

comment:15 by Collin Anderson, 10 years ago

This is why I use mysql :). If nothing else, would it be possible to at least move towards the direction of, by default, not allowing a new user if there's a username__iexact match? That way at least it wouldn't be possible to get duplicate usernames in the database before this issue gets noticed.

comment:16 by Collin Anderson, 10 years ago

Cc: cmawebsite@… added

comment:17 by Tim Graham, 10 years ago

The appropriate place to have discussion on a ticket that's been closed as "won't fix" is the DevelopersMailingList.

comment:18 by Tim Graham, 8 years ago

Component: Contrib appscontrib.auth
Type: defectCleanup/optimization

comment:19 by Tobias Wiese, 7 years ago

Cc: Info-Screen@… added
Note: See TracTickets for help on using tickets.
Back to Top