Django Aware

« | Home | »

Authenticating Using Email vs Username

By Paul Kenjora | May 18, 2008

A few weeks back I posted the full source for user logins and password recovery under Everything A Django Developer Needs To Create Logins. There was a little bit of flack from some very passionate and smart individuals (James Bennet) insisting that this middle ware already exists in "contrib.auth;". On the other hand I received many emails thanking me for the post because it boiled down the login system for novice users. In the spirit of helping new people adopt Django and existing users improve it here is a back end modification to allow email based logins in addition to the traditional default username login.

The file: django/contrib/auth/backends.py

I started by creating a whole new backend but it turned out to be tons of copy and paste code. The solution above meets all the requirements for a backend interface and is fully compatible with all existing code. I basically created a decision function that checks if "username" or "email" was passed in as a parameter, then decided on the appropriate action. All extreme python developers please feel free to boil this down to a single line.

Now you can use two methods to authenticate, remember all imports etc… remain the same. Here are both interfaces you can use simultaneously.

user = authenticate(username=”some_username”, password=”some_password”)

user = authenticate(email=”some@emai.com”, password=”some_password”)

Thats about it, I guess the next step would be for the code to figure out if its an email or a username on the back end and pick the best one… there are pros and cons here.

PS: I’m looking for a really simple and clever way of adding OpenID to my projects. Everything I’ve found so far requires me to re-code either my site or the solution to make it sync up with my existing logins. I really just want a snippet of HTML for the templates and a single backend authentication function. I know Python OpenID libraries come in a separate directory, I want to keep them there.

Oh yeah… I’m posting the source code and templates for Everything A Django Developer Needs To Create Logins converted to new forms next week…

Topics: Model Revisions, Tutorial | Comments

  • zoltanctoth
    I have just run into this issue by developing my first django project. I still cannot see the drawbacks of implementing this in django. The aim of a framework should be to be as general as possible if it does not lead to a major tradeoff.
  • cwurld
    Hi - I implemented something like this a few years ago. I am kind surprised it is not builtin by now. I could not find James Bennet's discussion of this topic.

    The website I run, requires users to login and our users are sales and marketing types (generally not very tech savy). Login is by far our biggest problem. Our users have a difficult time remembering a username. They are much better at remembering their email address. Also, we need to have their email address for password recovery.

    If we used a username for login and did not require an email address for each user, we would spend half our day reminding users of their username or creating new passwords for them.

    I have implemented OpenID on our development site and it works pretty well. But I am reluctant to go live with it because I think our users will be absolutely freaked out by it; too much magic.
  • oh...and your authenticate and get_user functions should be explicitly returning None as the last line
  • btw..here is your 1 liner..using the and/or trick

    def authenticate(self, **credentials):
    return 'username' in credentials and self.authenticate_by_username(**credentials) or self.authenticate_by_email(**credentials)
  • Andrew
    Email logins may be convenient for website administrators but in my experience is a hassle. If I don't remember which email address used to register I have to reregister. They are also longer to type if not saved by the browser password manager on the computer I happen to be on. On the other hand, prefer to use my regular login name that is short and obscure enough to be accepted everywhere.

    OpenID is the real solution, though. Please add OpenID support here!
  • Paul: actually GMail didn't address anything, plussed-emails have been around for much longer than Gmail. Granted they may have been the first "big" email provider to provide them.
  • Gmail has addressed this issue, you can have multiple email addresses at the same account for example:

    lastname@gmail.com
    lastname+djang@gmail.com
    lastname+wife@gmail.com
    lastname+husband@gmail.com

    I use it mainly as lastname+website@gmail.com to track which sites are spamming me but I've also used it to differentiate accounts on the same service.

    Granted this only works with gmail but if youre sharing an email account you'll need unlimited storage. Also shared email accounts imply shared website accounts and probably imply 0.01% of the population, other 99.99% will find it easier to use their email.
  • Laundro
    I can't remember where, but I once heard a website owner reverting to username based login, because a few of his users complained that they shared their email addresses with their spouse/significant others. I guess the same problem occurs when only allowing unique email addresses upon sign-up.

    On the other hand, in these days of free email accounts being available ubiquitously, one could argue the problem lies with the user foremost.
  • i love using email as authenticating name
    people might not be able to choose a certain username cause it has been used, but the email address is unique for anyone
    nice try!
  • Julian
    Q: What if user changes its main email address someday?
    A: He logs in with that address.
  • NiKo
    Email based logins? What if user changes its main email address someday? I'd definitely prefer good old plain usernames (or maybe openids).

    Disclaimer: I'm certainly not as smart as James Bennet ;-)
blog comments powered by Disqus