Code

Opened 4 years ago

Closed 4 years ago

Last modified 4 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: mattmcc 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: UI/UX:

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 mattmcc 4 years ago.

Download all attachments as: .zip

Change History (6)

Changed 4 years ago by mattmcc

comment:1 Changed 4 years ago by dmarble

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement set
  • Summary changed from User.username now allows '@', admin login should too. to 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 Changed 4 years ago by dmarble

  • Summary changed from Admin login should support email addresses. User login already does. to 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 Changed 4 years ago by 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.

comment:4 Changed 4 years ago by lrekucki

  • Resolution set to duplicate
  • Status changed from new to closed

Duplicates #7591 and #8342.

comment:5 Changed 4 years ago by kmtracey

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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.