Allow username to be longer than 30 characters to use e-mailaddresses as username

[wim@…]

Some email addresses are longer than 30 characters. It is not possible to use those as a username, except by monkey patching / overwriting django's default User model.

I would like to set the constraint less strict and allow for usernames to be up to 128 characters for example, like the password.

[wim@…]

patch for 128-char usernames

[wim@…]

patch for making usernames 128 characters

[wim@…]

Obviously I added the wrong patch, please use the second one.

[Aymeric Augustin]

This is a duplicate of #7591, see comment number 4 for a solution.

A Google search for "site:code.djangoproject.com email as username" turns up several tickets related to this controversial topic.

[wim@…]

Hi Aymeric Augustin,

Thanks for looking into the ticket. I've seen a lot of different custom EmailBackEnds on google today, actually that's why I think we need one in Django, because there is a demand. Django claims to encourage rapid development, I believe it should have this option. Allowing logging in using a username and not using an e-mail seems like an arbitrary decision to me, not a well-argumented one.

For me implementing nr. 4 is not a proper solution, several problems are outlined here:
​http://groups.google.com/group/django-developers/browse_thread/thread/61c15301a89d88be. Moreover, the argument being used ("it is easy to do it yourself") sounds similar to the argument against truncatechars.

My belief is that it might be a very easy change to allow for longer usernames. I'm wondering what are the reasons against it?

I am reopening this ticket, though I'm not sure if it's the right way to do things, I'm sorry if I am mistaken. Again, thanks for your time looking into this!

[Aymeric Augustin]

I see that you've started a discussion thread on django-developers. This is a good idea for two reasons:

• Jacob Kaplan-Moss issued a "wontfix" on this idea in #7591, and the canonical way to reverse a "wontfix" by a core developer is to obtain a consensus on the mailing list;
• there's no obvious way to implement username as login — as you say, many people have attempted to resolve this problem in different ways, with more or less convincing results.

Let's keep this ticket as "unreviewed" for now, we'll see in a few days where the discussion goes.

For the record, and for what my opinion is worth, I think that this issue won't be solved until someone spends a few months (full-time) to write the next version of django.contrib.auth, typically in the context of a GSoC: https://code.djangoproject.com/wiki/SummerOfCode2011#Enhancedauth.user — which is covered by #3011.

[Russell Keith-Magee]

No, let's not keep this as unreviewed. It ain't gonna happen like this.

There is a very good reason that this proposal keeps getting rejected, and that reason hasn't changed - we dont have a way to manage the data migration. We simply *cannot* change the length of the username field because we can't change the existing databases of almost every Django install in existence.

The core-endorsed ticket for this problem is #3011. The patch on that ticket isn't endorsed, but it points at the real problem - a need to be able to specify a custom User model. There have been several discussions directed at this problem, and I'm hoping to get a posse discussing this at the upcoming DjangoCon sprints. If you want background on some approaches that might work (and some that won't) search the archives for Lazy Foreign Key.