Opened 16 years ago

Closed 10 years ago

Last modified 6 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 Changed 16 years ago by Adrian Holovaty

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 Changed 16 years ago by paul@…

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 Changed 16 years ago by Adrian Holovaty

Resolution: wontfix
Status: reopenedclosed

We just don't have time.

comment:4 Changed 14 years ago by Farhan Ahmad

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 Changed 11 years ago by anonymous

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 Changed 11 years ago by Danilo Bargen

Cc: Danilo Bargen added

comment:7 Changed 10 years ago by tsal@…

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 Changed 10 years ago by Russell Keith-Magee

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 Changed 10 years ago by anonymous

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 Changed 9 years ago by bryce2@…

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

comment:11 Changed 9 years ago by Russell Keith-Magee

@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 Changed 9 years ago by mkhalil28@…

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 Changed 8 years ago by Carlos Killpack <carlos.killpack@…>

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 Changed 8 years ago by Oliver Ewert

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 Changed 8 years ago by Collin Anderson

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 Changed 8 years ago by Collin Anderson

Cc: cmawebsite@… added

comment:17 Changed 8 years ago by Tim Graham

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

comment:18 Changed 7 years ago by Tim Graham

Component: Contrib appscontrib.auth
Type: defectCleanup/optimization

comment:19 Changed 6 years ago by Tobias Wiese

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