Russ, Thanks so much for getting back to me! I shouldn't have posted that without my code in front of me... (was posting from my phone, in bed)
It turns out that I did NOT have AUTH_USER_MODEL set. I had AUTH_PROFILE_MODULE set. I changed it to AUTH_USER_MODEL and followed the custom user model example in the docs. I was really reluctant to do so earlier because the docs make it sound like everything is pain moving forward with a custom user model. Is it? On Monday, June 17, 2013 6:50:23 PM UTC-5, Russell Keith-Magee wrote: > > > On Mon, Jun 17, 2013 at 10:31 PM, Evan Stone <[email protected]<javascript:> > > 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.
