User registration should extend default user model not replace about book2-exercises HOT 4 CLOSED

There are multiple ways to do this. Replacing or extending. The warning is not against replacing, but ensuring that you specify the appropriate settings prior to running syncdb so everything is handled correctly.

In book 2 replacing is presented as one way of doing things, in the third book it is changed to extending AbstractBaseUser. So both options are actually presented. That being said we have talked internally about standardising the two books so they both use the same method, which would probably be extending as you suggest. But we are still undecided.

I would say at this early stage (i.e. just creating a user model) it's hard to see which is the best practice. This choice I think is largely dependent upon other factors. Namely tying into the authentication methods used by other reusable applications you may want to incorporate.

For example using authentication with Django Rest Framework assumes you are using a Standard User Model, so there will be some work to get the authentication to work with that framework regardless if you extend or use a custom User model, although it's probably simpler if you extend.

Alternatively I have developed systems for certain corporates that had proprietary SSO requirements that necessitated having a custom user model.

Likewise several other applications have different requirements in terms of what they need / expect. So I would say evaluate the third party applications you plan on using and then do what makes the most since / causes the least amount of headaches when integrating.

Not sure if that helps or confusing the matter... :) But I hope it helps.

@mjhea0 feel free to chime in here.

from book2-exercises.

@j1z0, i understand your points, and agree with most of them.

But just to clarify things, in book 2 you create a model named User and on page 370 there is this: "NOTE: This model replaces the default User model."

That is it, the whole explanation of how to replace the user model is hidden. The questions that come to my mind: how and why replace the user model in the way you guys did?

So far, there are 4 ways i'm aware of to extend or replace the user model: one-to-one or foreignKey (widely use in django<=1.4), subclassing AbstractUser, subclassing AbstractBaseUser (taken from two scoops of django 1.5); and finally the way explained on chapter 21.

Where do we need user managers, like BaseUserManager, and why we need them? What are the strengths and pitfalls of that approach?

But here comes the really important part, IMHO, what is it that we need to do in order to make each and every one of those ways work?

OK, maybe explaining every single one of them is going to be time consuming and not on the scope of this book/exercise/course/project. In this case, pick one (preferably the most used or the one that will solve 90+% of the cases), and do it so well done that i will believe that this the one true way of doing things. In the end, insert a paragraph or two saying there are other ways, name them and point to the documentation or some other resource where i can find out more about it, like:http://www.caktusgroup.com/blog/2013/08/07/migrating-custom-user-model-django/
those guys have a pretty good tutorial on using AbstractBaseUser.

Just to finalize, i need to say that i do not want to cause a flamewar or something. My only purpose is to argue, in the good way, in order to achieve the best course i can get.

Also, i just put this on book 2 repo because user registration starts on book 2, but my main interest is book 3.

from book2-exercises.

This is something that I have been meaning to refactor. I am going to look at extending the user model as I did in this code - https://github.com/mjhea0/django-1.5-template/blob/89031a2667ef3ca856edffacaef887c6d7d45dfd/django-1.5-template/users/models.py

from book2-exercises.

updated - thanks!

from book2-exercises.