Opened 9 years ago

Closed 2 years ago

Last modified 8 months ago

#2273 closed defect (wontfix)

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

Reported by: mderk@… Owned by: adrian
Component: Contrib apps Version:
Severity: normal Keywords:
Cc: dbrgn, cmawebsite@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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 (17)

comment:1 Changed 9 years ago by adrian

  • Resolution set to wontfix
  • Status changed from new to closed

This backwards-incompatible change isn't worth making, but you can use your own authentication backend if you need case-insensitive usernames. Check out http://www.djangoproject.com/documentation/authentication/#other-authentication-sources .

comment:2 Changed 8 years ago by paul@…

  • Resolution wontfix deleted
  • Severity changed from major to normal
  • Status changed from closed to reopened

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 8 years ago by adrian

  • Resolution set to wontfix
  • Status changed from reopened to closed

We just don't have time.

comment:4 Changed 6 years ago by thebitguru

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: http://blog.shopfiber.com/?p=220

comment:5 Changed 3 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 3 years ago by dbrgn

  • Cc dbrgn added

comment:7 Changed 2 years ago by tsal@…

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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 2 years ago by russellm

  • Resolution set to wontfix
  • Status changed from reopened to closed

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 2 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 19 months ago by bryce2@…

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

comment:11 Changed 19 months ago by russellm

@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 17 months ago by mkhalil28@…

in django/contrib/auth/models.py

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 months 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 months ago by ollytheninja

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 https://docs.djangoproject.com/en/dev/ref/contrib/auth/#django.contrib.auth.models.User.username would be a step in the right direction.

comment:15 Changed 8 months ago by collinanderson

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 months ago by collinanderson

  • Cc cmawebsite@… added

comment:17 Changed 8 months ago by timgraham

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

Note: See TracTickets for help on using tickets.
Back to Top