Yet another solution:
from django.contrib.auth import get_user_model
from django.contrib.auth.backends import ModelBackend
from django.db.models import Q
class EmailOrUsernameModelBackend(ModelBackend):
"""
Authentication backend which allows users to authenticate using either their
username or email address
Source: https://stackoverflow.com/a/35836674/59984
"""
def authenticate(self, request, username=None, password=None, **kwargs):
# n.b. Django <2.1 does not pass the `request`
user_model = get_user_model()
if username is None:
username = kwargs.get(user_model.USERNAME_FIELD)
# The `username` field is allows to contain `@` characters so
# technically a given email address could be present in either field,
# possibly even for different users, so we'll query for all matching
# records and test each one.
users = user_model._default_manager.filter(
Q(**{user_model.USERNAME_FIELD: username}) | Q(email__iexact=username)
)
# Test whether any matched user has the provided password:
for user in users:
if user.check_password(password):
return user
if not users:
# Run the default password hasher once to reduce the timing
# difference between an existing and a non-existing user (see
# https://code.djangoproject.com/ticket/20760)
user_model().set_password(password)
Fixes:
- By default,
@
is not prohibited in the username field, so unless custom User model prohibits@
symbol, it can’t be used to distinguish between username and email. - Technically, there can be two users using the same email, one in the email field, the other in the username. Unless such possibility is restricted, it can lead to either user not being able to authenticate, or unhandled
MultipleObjectsReturned
exception ifUserModel._default_manager.get(Q(username__iexact=username) | Q(email__iexact=username))
is used. - Catching any exception with
except:
is generally bad practice
Downside – if there are two users, using the same email, one in the username, the other in email, and they have the same password, then it’s prone to authenticating the first match. I guess the chances of this is highly unlikely.
Also note: any of the approaches should enforce unique email
field in the User model, since the default User model does not define unique email, which would lead to either unhandled exception in case User.objects.get(email__iexact="...")
is used, or authenticating the first match. In any case, using email to login assumes that email is unique.