Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#13928 closed (duplicate)

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

Reported by: Matt McClanahan Owned by: nobody
Component: contrib.admin Version: 1.2
Severity: Keywords: admin email login
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

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.

Attachments (1)

13928-1.diff (1.2 KB ) - added by Matt McClanahan 14 years ago.

Download all attachments as: .zip

Change History (6)

by Matt McClanahan, 14 years ago

Attachment: 13928-1.diff added

comment:1 by dmarble, 14 years ago

Patch needs improvement: set
Summary: User.username now allows '@', admin login should too.Admin login should support email addresses. User login already does.

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

comment:2 by dmarble, 14 years ago

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

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"

comment:3 by dmarble, 14 years ago

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.

comment:4 by Łukasz Rekucki, 14 years ago

Resolution: duplicate
Status: newclosed

Duplicates #7591 and #8342.

comment:5 by Karen Tracey, 14 years ago

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.

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