#2273 closed Cleanup/optimization (wontfix)
django.contrib.auth.models.User: username is case-sensitive
Reported by: | 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 |
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 (19)
comment:1 by , 18 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 18 years ago
Resolution: | wontfix |
---|---|
Severity: | major → normal |
Status: | closed → 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 by , 18 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
We just don't have time.
comment:4 by , 16 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: http://blog.shopfiber.com/?p=220
comment:5 by , 13 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 , 13 years ago
Cc: | added |
---|
comment:7 by , 12 years ago
Resolution: | wontfix |
---|---|
Status: | closed → 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 by , 12 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → 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 by , 12 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 , 11 years ago
So what's wrong with making the change, by default applicable only to new sites?
comment:11 by , 11 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 , 11 years ago
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 by , 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 , 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 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 by , 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 , 10 years ago
Cc: | added |
---|
comment:17 by , 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 , 9 years ago
Component: | Contrib apps → contrib.auth |
---|---|
Type: | defect → Cleanup/optimization |
comment:19 by , 8 years ago
Cc: | added |
---|
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 .