On Fri, 30 Mar 2012 17:35:16 +0300, Tom Evans <[email protected]>
wrote:
On Fri, Mar 30, 2012 at 10:39 AM, Stratos Moros <[email protected]>
wrote:
You can read the proposal nicely formatted here:
https://gist.github.com/8dd9fb27127b44d4e789
Hi Stratos
It's a long proposal, so this is a brain dump of bits that I find
interesting/worrisome.
Hi Tom.
I'm answering your 3 questions together because they are related to each
other.
In my proposal, a user model represents an authentication/authorization
scheme. This is why you have to mixin the authentication scheme directly
in the model. All other information, such as first_name, last_name etc.
should live in the user's profile.
The idea isn't to remove custom profiles, but to let developers control
where they're used. The example I provided about adding custom profiles
was rather bad. The way I expect most developers to add a fields to a user
is:
class CustomUser(SomeMixins):
profile = models.ForeignKey(UserPorfile)
This way you can allow your frontend users to log in with, say, either
with username & password or openid and have a single profile between them,
while allowing your backend users to login with credentials from an LDAP
server and have a different profile for them.
This is why authentication backends are deprecated. If you can't specify
which authentication mechanism is used for each user model, you can't
easily accomplish the above scenario. You would have to have a single
table to represent the two different profiles and you would somehow make
sure that a user trying to log in with facebook doesn't go through the
LDAP server.
This is also why the identity in the user model is a method and not a
field. If you want a single user to be authenticated in multiple ways, you
can override the identity method and return the same value.
Perhaps the profile field should be made part of the user contract, but
this would be an annoyance in cases where you don't want to store any
additional information about the users, but use them only for
authorization purposes (ie. I don't care about his info, I just want to
know if he can access this page).
Having login and logout be part of the user model was one of the things
that I wasn't sure about. The reason I put them in the user model is to
decouple the whole process from the session. This way an authentication
scheme that doesn't want to use the session to store a logged in user can
do so. The common case would obviously be to store them in the session, so
I included the SessionAuthenticationMixin.
The same goes for authorization. Inheriting from a mixin implementing the
authorization contract would probably add a foreign key to the table
storing the permissions plus a few methods to query it. This way you can
handle different user models' permissions in completely different ways.
Thanks for the feedback. I hope I've answered your questions.
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
