[code]
from django.contrib.auth.admin import UserAdmin
admin.site.register(CustomUser,UserAdmin)
[/code]

Then, it’s also possible to set/change the password of the user

from django.db.models import signals

def create_profile_for_user(sender, **kwargs):
    if kwargs['created']:
        p = Profile() # 'Profile' is my custom User model
        p.__dict__.update(kwargs['instance'].__dict__)
        p.save()

signals.post_save.connect(create_profile_for_user, sender=User)

I hope this helps someone else!

- Thiago

If you have to add those four lines to each view, that’s a fair bit of extra code, especially if you have lots of views. You could write a custom decorator to do that and set request.user or request.custom_user in the decorator.

Another thing to consider is if you are making an extra call to the database when you get request.user.custom_user. The advantage to custom middleware or authentication backend is that you only need to hit the database once to get the custom user object.

@login_required
def my_view(request):
  try:
     cutom_user=request.user.custom_user
  except Custom_User.DoesNotExist:
     return HttpResponseRedirect(reverse('custom_client_login'))

i would like to have your feedback :)

Thanks in advance,

Sergio Hinojosa

Thanks a million. I did look in the source and saw that authenticate method is setting the backend. Coming from Java background, I thought the child method will call super() automatically and did not know that I should call the parent directly.

It works! BEAUTIFUL! You made my day!

Thanks again for the example.

I think instead of making an instance of CustomUserModelBackend and calling authenticate on it, you should just call the authenticate function which is in django.contrib.auth.

If you look in the source you can see it calls the backend’s authenticate method and then sets the backend attribute on the user object.

It uses the backend(s) configured in your settings.py, so it will be using the CustomUserModelBackend anyway.

So, more like:

from django.contrib.auth import authenticate
...
user = authenticate(email=email, password=password)
...
login(request, user)

‘CustomUser’ object has no attribute ‘backend’

And the code is below:

def my_view(request):
    if request.method == 'POST': # If the form has been submitted...
        form = LoginForm(request.POST) # A form bound to the POST data
        if form.is_valid():
            email = request.POST['email']
            password = request.POST['password']
            c = CustomUserModelBackend()
            user = c.authenticate(email=email, password=password)
            if user is not None:
                if user.is_active:
                    login(request, user)

When I looked into the super authenticate method, it does set the backend. Not sure why it’s not being set in my case.

Note: I am able to authenticate the user fine, but login fails with the given error message.
My settings.py has following entry for AUTHENTICATION_BACKENDS:

AUTHENTICATION_BACKENDS = (
    'learnsite.events.AuthBackends.CustomUserModelBackend',
)

Any insight will be appreciated.

Each customer is a company, and can have several users under it, so unfortunately I can’t go with the route of having the CustomUser be the Customer.

One thing I realized yesterday after posting my question here, was that when I go into the administration I can go and create a CustomUser as part of my application, and that will of course create the entries in both tables (and allows me to choose which Customer the new user belongs to). Since all the users will be created this way, I think I can manage without writing a new manager :-)

Best,
Steinn

You are correct that creating a User in admin will not cause a CustomUser to be created. You need to make it so CustomUsers are created in admin. See comment #8 above for an idea of how to do that.

Does Customer need to be a separate model from CustomUser? If not, you could use Customer as your custom user class — that’s what I’m doing in my current project.

If they do need to be separate, you could make the customer property of CustomUser optional so a CustomUser can be created first then a Customer can be created and assigned. That’s a bit messy, though.

An alternative is to write your own manager for CustomUser and give it a create_user method that does the right thing. You can look at the source in django/contrib/auth/models.py to see what the default method does (not much), copy and customise.

If there is always one Customer for each CustomUser, it seems like maybe they should be the same model, so that would be the first thing to consider.