Admin login should no longer give an error on '@' character (email addresses). User login already supports email address entry.

[Matt McClanahan]

As of [12634], User.username can hold an e-mail address, albiet only a very short one. It might be time to remove the email-as-username blocking code from AdminSite.login.

[dmarble]

Second this. Just ran into this problem with an installation of Pinax, which allows users to specify either usernames or email as the default and only way to login (using AUTHENTICATION_BACKENDS). Upon setting this to email addresses, I can't use the admin at all unless I login through the front of my website and subsequently browse to /admin/.

Note that the patch given only covers one of the files. The code preventing email addresses for admin login is in two places:

django.contrib.admin.sites -- lines 325-336

django.contrib.admin.views.decorators -- lines 58-66

[dmarble]

For those searching for this issue, the typical error message is: "Your e-mail address is not your username" or "Usernames cannot contain the '@' character"

[dmarble]

I noted the lines where the '@' checking occurs, but the problem is tougher than just commenting out that code. We need to make use of the actual authentication backends, but the problem is those backends will be looking for keyword arguments. I don't have a good solution for this, other than changing the existing authentication mechanism to allow for unnamed *args instead of the current credentials. I'm getting by with a horrible hack for now.

[Łukasz Rekucki]

Duplicates #7591 and #8342.

[Karen Tracey]

I do not understand how these checks are preventing logging in -- they are only done when authenticate() fails to return a user. They are an attempt to provide a more helpful error message in case the user has mistakenly tried their email address as username, they do not prevent the authentication attempt in the first place. Per original description for #8342 the problem only occurs when you try to login with an email (or username) that does not exist, and the problem is that the message is misleading. It used to be misleading only when you had a custom authentication backend in place but it is now just flat-out wrong since '@' is a valid character in the username.