Using email instead of username in extended "User" model?

8 views
Skip to first unread message

Dana

unread,
Aug 2, 2009, 11:38:25 AM8/2/09
to Django users
Hello All,

I am looking to create a user model that extends the Auth "User"
model, like how James Bennett outlines in his article "Extending the
User Model" [1] by creating a FK to the "User" model and everything is
going fine other than one issue.

I would like to make "email" become the unique field and not need
"username" when creating user accounts. Now, I don't mind using
username for the Django admin, but for my own user section on the
front end I want people creating accounts/logging in using an email. I
am wondering if there is any clear way of doing this without having to
roll my own auth app?

I played with the idea of having my "save()" function create a random
username when saving but that is obviously an ugly solution. Is there
an easier way to do this that I am overlooking?

Thanks for all your time!
Dana W

[1] http://www.b-list.org/weblog/2006/jun/06/django-tips-extending-user-model/

David Koblas

unread,
Aug 2, 2009, 11:56:40 AM8/2/09
to django...@googlegroups.com
Just to add my $0.02 cents to this, I too would like a better way to
extend django.contrib.auth.models.User than the current approach. The
two biggest "problems" that I have are:

* Everything depends on django.contrib.auth.models.User -- which means
that while you could swap out your authenticator you still basically
have to go and rip apart everybody's applications to support your user
object.
* To the above point, it also means that to construct your own User
object means you can't use contrib.admin since it depends on the User
object.

What would be really nice is to have something like:
django.auth.interface.User

Which in turn would instantiate something from settings.USER_MODEL
(default contrib.auth.modes) this might mean you could subsume
AUTH_PROFILE_MODULE into the USER_INSTANCE for most developers. Up shot
is that I can now still use public applications and the admin system,
but now somebody can just create a "facebook.models.User" class that
mirrors using facebook as the authenticator and get everything for free...

--koblas

Darek

unread,
Aug 2, 2009, 12:21:58 PM8/2/09
to Django users

cootetom

unread,
Aug 2, 2009, 2:39:34 PM8/2/09
to Django users
Another option you have is to modify the User model directly in the
django source code.

You will need to edit:
django.contrib.auth.models.User
django.contrib.auth.forms.UserCreationForm
django.contrib.auth.forms.AuthenticationForm

Find the username field and use the forms.EmailField instead.
> > [1]http://www.b-list.org/weblog/2006/jun/06/django-tips-extending-user-m...

Russell Keith-Magee

unread,
Aug 2, 2009, 8:36:08 PM8/2/09
to django...@googlegroups.com
On Sun, Aug 2, 2009 at 11:56 PM, David Koblas<kob...@extra.com> wrote:
>
> Just to add my $0.02 cents to this, I too would like a better way to
> extend django.contrib.auth.models.User than the current approach.  The
> two biggest "problems" that I have are:
>
> * Everything depends on django.contrib.auth.models.User -- which means
> that while you could swap out your authenticator you still basically
> have to go and rip apart everybody's applications to support your user
> object.
> * To the above point, it also means that to construct your own User
> object means you can't use contrib.admin since it depends on the User
> object.
>
> What would be really nice is to have something like:
>    django.auth.interface.User
>
> Which in turn would instantiate something from settings.USER_MODEL
> (default contrib.auth.modes) this might mean you could subsume
> AUTH_PROFILE_MODULE into the USER_INSTANCE for most developers.  Up shot
> is that I can now still use public applications and the admin system,
> but now somebody can just create a "facebook.models.User" class that
> mirrors using facebook as the authenticator and get everything for free...

You aren't the first person to suggest this, and it's something I'm
interested in looking at in the v1.2 timeframe. This is a very common
question, and one for which Django needs to have a clear and well
documented solution. Ticket #3011 has one solution; I'm not completely
convinced that the patch on that ticket is the whole solution, though.

Yours,
Russ Magee %-)

Dana

unread,
Aug 2, 2009, 10:12:27 PM8/2/09
to Django users
Modification of Django code is not really a path I want to take, I'd
prefer a cleaner approach, but thanks for the suggestion!

Dana

unread,
Aug 2, 2009, 10:33:02 PM8/2/09
to Django users
Tried using that but seems to not do what I need. I couldn't get an
email address to save as a password and I am not willing to modify
Django or hack my database to do it just yet.

On Aug 2, 9:21 am, Darek <dariusz.ormi...@gmail.com> wrote:
> tips&tricks: Email addresses for user name:http://www.djangosnippets.org/snippets/74/
>

Dana

unread,
Aug 2, 2009, 11:21:33 PM8/2/09
to Django users
Oops i mean username, not password.

Im not clear on how I can get this to override the django login
functionality. Im reading more up on custom auth backends but Ill
admit it's a little confusing.

Anyone have a finished example of how I can get Django to use email to
login (either by making email the username field or some other
method), I learn best by example.

Cheers,
D

Malcolm Tredinnick

unread,
Aug 2, 2009, 11:44:10 PM8/2/09
to django...@googlegroups.com
On Sun, 2009-08-02 at 20:21 -0700, Dana wrote:
> Oops i mean username, not password.
>
> Im not clear on how I can get this to override the django login
> functionality. Im reading more up on custom auth backends but Ill
> admit it's a little confusing.

You write a custom authentication function that compares the username
and password supplied by the user in the login form against the email
address and password fields in the User model -- fetch the User
instance(s) matching the email address and then use the check_password()
method on the User instance to see if it's valid.

It should only a couple of lines of code in the skeleton code described
here:
http://docs.djangoproject.com/en/dev/topics/auth/#writing-an-authentication-backend

Regards,
Malcolm


cootetom

unread,
Aug 3, 2009, 9:26:50 AM8/3/09
to Django users
When I first started using django I was surprised that it limited
usernames and didn't allow email address's by default. It is probably
the only thing in the whole framework that I have wanted to change.
Yes it would be nice to have a clear solution rather than the approach
I have taken which is to modify the source code directly. Although
when I was faced with this problem originally I didn't like any of the
solutions that were about. In my opinion, this sort of thing should be
handled at the framework level.

Dana

unread,
Aug 3, 2009, 4:13:05 PM8/3/09
to Django users
Ok, I understand the login part but what about registration? Wouldn't
the user's need a username still? Or am I misunderstanding... And what
about Django admin, it would still need a username correct?

On Aug 2, 8:44 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> here:http://docs.djangoproject.com/en/dev/topics/auth/#writing-an-authenti...
>
> Regards,
> Malcolm

Dana

unread,
Aug 3, 2009, 4:15:08 PM8/3/09
to Django users
Yes, I agree that this is probably the best way to do it as I see now
and I may well do that change, Im just hoping that Im missing some way
to get around hacking up Django to get what I want... This seems like
the one thing in the framework that is suboptimal... too bad because
it is so crucial.

Elliott

unread,
Aug 3, 2009, 4:50:48 PM8/3/09
to Django users
Another way to do it is to create subclasses of all the relevant
classes and forms. It's easy enough to create middleware that replaces
django's default user object with your own, and it's also very easy to
set the admin up to use your user model instead of the default.

djang...@gmail.com

unread,
Aug 3, 2009, 5:04:13 PM8/3/09
to django...@googlegroups.com
+1 thought that from the beginning!

-- Sent from my Palm Pre


prabhu S

unread,
Aug 3, 2009, 6:34:42 PM8/3/09
to Django users
Going a step backward, why cant you make username same as email. Have
a custom login_required decorator that uses email and password to
authenticate, override registeration pages and not show username
field?

It seems to work for me.
> [1]http://www.b-list.org/weblog/2006/jun/06/django-tips-extending-user-m...

Malcolm Tredinnick

unread,
Aug 3, 2009, 7:23:55 PM8/3/09
to django...@googlegroups.com
On Mon, 2009-08-03 at 13:13 -0700, Dana wrote:
> Ok, I understand the login part but what about registration? Wouldn't
> the user's need a username still? Or am I misunderstanding... And what
> about Django admin, it would still need a username correct?

Nothing stops you from creating a random string to populate the username
field with. It has to contain a unique identifier and it's often useful
if that is actually identifiable -- perhaps created from an amalgam of
the user's first and last names or something -- but it could be entirely
random, providing it is unique.

So when you are registering the user, just create a username string
however you like. The user themselves doesn't have to know or care what
it is. The thing is, their username won't change, their email address
might (one of the many small problems with email addresses as unique and
unchanging identifiers).

Regards,
Malcolm


Dana Woodman

unread,
Aug 5, 2009, 1:04:36 AM8/5/09
to django...@googlegroups.com
Yeah that seems like the option Ill go with since it is probably the most clean and future compatible. My user's dont need to log into django admin anyways so that should suffice. Thanks everyone for the feedback!

Cheers,
Dana

Saikat Chakrabarti

unread,
Aug 9, 2009, 10:26:31 PM8/9/09
to Django users
Just some more info on this -
I use http://www.davidcramer.net/code/224/logging-in-with-email-addresses-in-django.html
for logging in using emails. There is some discussion of this topic
on http://groups.google.com/group/django-users/browse_thread/thread/c943ede66e6807c/2fbf2afeade397eb?pli=1
. And for registration, I generate a username for each user using the
code at http://www.djangosnippets.org/snippets/723/ . This is mostly
a rehash of what's been already said, but it seems like a summation of
what I can find on the topic currently.

-Saikat

On Aug 4, 10:04 pm, Dana Woodman <woodman.d...@gmail.com> wrote:
> Yeah that seems like the option Ill go with since it is probably the most
> clean and future compatible. My user's dont need to log into django admin
> anyways so that should suffice. Thanks everyone for the feedback!
>
> Cheers,
> Dana
>
> On Mon, Aug 3, 2009 at 4:23 PM, Malcolm Tredinnick <malc...@pointy-stick.com
Reply all
Reply to author
Forward
0 new messages