Relax character restrictions on auth usernames

[Armin Ronacher]

We have to use the auth module with legacy data and need to support more characters. Additionally the regexp there disallows german umlauts. There should be a way to configure the validator used for the username without monkeypatching.

[munhitsu]

What about adding sth like this to settings.py

AUTH_USER_VALIDATORS = (validators.myValidator)

Default settings.py and Django level settings will contain a line like:

AUTH_USER_VALIDATORS = (isAlphaNumeric)

[Jacob]

I'm not at all a fan of a list of validators in the settings module, but yes, we should relax characters allowed in usernames -- another common request is to allow the use of email addresses as usernames.

Custom registration/signup forms can deal with further restrictions.

[Bob Gao]

a patch for this ticket

[Marc Fargas]

Reviewing the patch,

• the setting should be r'^{\w+$' (the 'r' to denote it's a regular expression).}
• the setting should be documented in docs/settings.txt and (maybe) docs/authentication.txt not only on the tutorial.

Anyway, this will solve that on oldforms, contrib.auth still uses them!

Maybe when contrib.auth moves to newforms we could think about making it easy to subclass contrib.auth forms ;)

[Bob Gao]

an improved version

[Bob Gao]

yes, i just slove the problem on oldforms.

[Jacob]

I'm still not a big fan of this patch. We don't need Yet Another Setting; we just need to relax the current restrictions.

Also, luli, please don't mark your own tickets as "Ready for checkin"; a triager or contributer needs to do that.

[Bob Gao]

i have committed another patch

[Pete Crosier]

Think there's an issue with the old django/contrib/auth/tests.py which is breaking the pretty diff display unfortunately - the patch I've attached goes really liberal on usernames. At the moment, User.objects.create_user doesn't actually enforce the current restrictions, hence it not needing to be changed in the patch.

[Pete Crosier]

A more liberal approach to relaxing username restrictions

[Pete Crosier]

OK, the pretty diff is working after removing the "\ No newline at end of file" which was causing the breakage!

[railk]

The patch does not apply properly without the "\ No newline at end of file". Sounds like the pretty diff is broken.

[Michael Richardson <michael@…>]

See also: #3011

[dc]

Also, see #6588 for a patches.

[Torsten Bronger]

I think it's time to merge the ideas on this one.

According to this issue, we want to have all alphanumeric characters from Unicode allowed in usernames. According to #6588, also dots should be allowed, and according to <​http://permalink.gmane.org/gmane.comp.python.django.user/88509>, dashes might be highly sensible, too.

So what about re.compile(r'^[-@.\w]+$', re.U)? Or do we need even more? (E.g. :#*+~'$%&()[]{}!^)

[anonymous]

The basic problem involves having a username/restrictive user model in general... see #3011

[Torsten Bronger]

So we should close this one, and post links to #6588 and this one to #3011?

[Torsten Bronger]

Actually, I think we should consider them separate issues. #3011 is a large beast, and this one is pretty light-weight, so I'm afraid of waiting for a solution much longer than necessary. Additionally, we discuss about changing Django's default behaviour here, whereas #3011 talks about extensibility. I think that Django should support more usernames out-of-the-box.

The demand that occurs again and again (on the mainglist and in the tickets) is that you have to include existing user databases. In my case, we must authenticate against an external Windows Active Directory with pre-existing usernames. I think that this is an important use case, and I think that characters like dot, dash, and plus are pretty common outside Django.

[leond]

I really don't understand the ticket system very well. That's why I am always asking myself, after finding some tickets discussing a problem I have at the moment, why this takes so long? This ticket was opened two years ago and I see that this is a common problem which is demanded again and again. So for the sake of the principles of DRY this ticket should be considered of.

There should be implemented something like a setting to customize the regex strings used in auth/forms.py.

I will change some properties, because they are out-of-date.

• lulin's last comment was in 2007, I will reassign this ticket to anonymous.
• Further I change the triage stage to unreviewed.
• The Component is clearly authentication.

[Karen Tracey]

Replying to leond:

Understanding the ticket system does not have a lot to do with understanding why something may take a long time. It isn't the ticket system or any process associated with it that holds things up. In this particular case the original patches apparently added yet another setting, which Jacob is opposed to (see ​http://code.djangoproject.com/ticket/5786#comment:10). So calling for another setting to fix this is not likely to move things forward. Nor is changing the ticket state from Accepted to Unreviewed -- why did you feel Accepted was "out of date"? Jacob, in that same comment, indicated he agrees that the character restrictions need to be relaxed. So near as I can see this ticket should still be Accepted. The triage states are described here:

​http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage

Another reason this ticket got slowed down is likely that the fixes proposed involved changing the validators for the field, and with newforms in progress validators were on their way out (to be replaced by model validation, which is still not yet in trunk). Changing code that is about to be removed/replaced is generally not high priority. I don't see that anyone has posted what changes are actually required now that newforms have replaced oldforms and validators are gone.

[alextreme]

Allows common punctuation characters in username

[alextreme]

I've included a very simple patch (django-auth-username-characters.patch, 6 lines in 1 file) against Django 1.1 that eases the username restrictions. It allows the following characters (next to alphanumerics): @.+-_

The auth system actually works perfectly fine with these characters, it's only the admin forms that restrict input. This probably was different in the past.

I'm not sure if there was a rationale on restricting usernames (perhaps their use in URLs?) but this patch only allows a few more characters, those that probably cause the most annoyances.

No major changes, no extra settings and good enough until #3011 sees some progress. Tests and a review are welcome however.

[leond]

I did it this way! I just overwrote these classes and now it's working and it's really easy!

[Luis Bruno]

add to alextreme's patch: change models.py help_text

[Luis Bruno]

This is what I'm using in my in-house Django fork. Can this find its way into the 1.2 series?

[clayg]

Triage Stage: Design decision needed

"we just need to relax the current restrictions"

lbruno's patch looks good to me...

[clayg]

diff from the top-level trunk directory including tests

[clayg]

patch -p1 < django-auth-username-relax-character-restrictions.diff
applies cleanly from the root directory

./tests/runtests.py --settings=settings auth

---

Ran 44 tests in 1.649s

OK

Will the documentation get updated from the doc strings?
e.g.
​http://docs.djangoproject.com/en/1.1/topics/auth/#topics-auth

[leond]

First I was convinced that this had to be changed. Later I discovered a good workaround because of the following: If you change this in the module code, there will be developers who may be dissatisfied with the relaxed restrictions. Or there may be developers who still are not satisfied. It may be that there are alway unsatisfied developers, no matter how you rewrite the module code. So the best solution (in my opinion) is to simply put a piece of code into your own admin.py and your own forms.py. You can find it in the attachments. I uploaded them several months ago and it works really fine.

I am completely against changing the module code as that never satisfies every single developer! Please use the workaround I posted or take it as an idead to code a better one.

[Torsten Bronger]

Please change the character restrictions to the best common practice. It is highly unusual to forbid dash or dot in login names. Moreover, email addresses as logins are very common.

It is not about satisfying all; that's never the case for default values. Instead, it's about satisfying almost all. Given that almost all logins that I know allow more characters, I see no real use case for the very limited set being the default. From this it also follows that only very few Django installation are expected to break due to relaxed restrictions.

[Torsten Bronger]

I restore the "Accepted" tag of Jacob as in <​http://code.djangoproject.com/ticket/5786#comment:10>. I don't see why this was removed. As far as I can see, we have patches and tests now that use newforms, so the issues mentioned in ​http://code.djangoproject.com/ticket/5786#comment:25 are addressed.

Could some ticket triager come over and check ​the latest patch please? So that it can be marked "Ready for checkin". Thank you.

[Jacob]

(In [12634]) Fixed #5786: relaxed the validation for usernames to allow more common characters '@', etc.

This is really just a stop-gap until we come up with a improved way of handling
disparate auth data, but it should help us stretch a bit more milage out of the
current system.

Thanks to alextreme, lbruno, and clayg.

[Jacob]

Milestone 1.2 deleted