On Mon, Jun 17, 2013 at 10:31 PM, Evan Stone <e...@aquapony.com> 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 django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. For more options, visit https://groups.google.com/groups/opt_out.
