On Mon, Jun 17, 2013 at 10:31 PM, Evan Stone <[email protected]> wrote:
> Per the docs for Django 1.5, I have attempted to broaden the range of data > held in the default user model by making an extended user model with the > AbstractUser class. I made the model (called "Client") and listed it in > settings.py as the AUTH_USER_MODEL. Syncdb took it and it worked great. > Specifically, syncdb made a new MySQL table with all the default user > fields AND my own additional fields, followed by two related tables for > user permissions. I was pretty excited about all this until I tried to > authenticate a user. Apparently, the built-in authenticate method is still > pointing at the built-in user model. How can I point that method to my new > custom model instead? > > Fyi, I created new users in the Client model through the djangoized python > shell and used set_password to create the passwords. I checked the MySQL > tables to verify that my new user records in my Client table looked just > like a new user in the built-in user table (auth-user). They did. But they > won't authenticate. To double-check, I then made a new user in the built-in > user model and it authenticated just fine. > > I've read about coding custom authentication with a totally customized > user model--it looks quite involved and that really shouldn't be necessary > for what I'm doing, because my model isn't custom. I've simply extended the > existing user model and wish to authenticate users based on that model. > There has to be an easier way. Any advice? > > Hi Evan, It's difficult to say what's going on without seeing code. However, if AUTH_USER_MODEL is set as you describe, then the built-in User table shouldn't even be created, so it shouldn't be possible for the built-in auth_user table to be used for authentication purposes. So - it sounds like there's something wonky in your basic project configuration. The simplest test I can think of is to run ./manage.py createsuperuser. This command should ask you for all the REQUIRED_FIELDS on your model, and then store an object with superuser permissions in your custom User table. If this doesn't happen, then you know you have a low level configuration problem. createsuperuser doesn't get involved with any of the authentication code -- it's a very low level tool for dealing with the "User" model (whichever User that is), so it's a good test to see if your project is finding your custom User model. Another test would be to open a ./manage.py shell and run: $ from django.contrib.auth import get_user_model $ print get_user_model() If that doesn't point at your custom User model, you have a problem. As for your question about custom coding authentication -- this should only be needed if your custom User model doesn't meet the basic requirements of Django's User. If you have a single unique field that is an identifier (e.g., a username, and email address, or some other identifier of some kind), then you should be able to use Django's built-in authentication. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-users. For more options, visit https://groups.google.com/groups/opt_out.
