django.contrib.auth.get_user already uses BACKEND_SESSION_KEY to
decide from which backend to get user object.
To support multiple user models, we can just change the
AUTHENTICATION_BACKENDS setting to a dict just as DATABASES.
AUTHENTICATION_BACKENDS = {
'default': {
'BACKEND': 'django.contrib.auth.backends.ModelBackend',
'MODEL': 'django.contrib.auth.models.User',
},
}
Instead of a single global USER_MODEL setting, each app should have
its own USER_MODEL settings, like ADMIN_USER_MODEL,
COMMENTS_USER_MODEL .
I do not like `ForeignKey(settings.ADMIN_USER_MODEL or
settings.USER_MODEL)` . I prefer a combination of solution 2a and 2b
to that.
On 4月4日, 上午5时51分, Alex Ogier <alex.og...@gmail.com> wrote:
> Thanks for the response, Adrian.
>
> > 4. Third-party models should be changed to use something like "user =
> > UserField()", which would automatically create a foreign key to the
> > registered User model. If you change your registered User model after
> > you've created those third-party tables, you're in for trouble. Don't
> > do that.
>
> > 5. Django provides some generic APIs for getting at the registered
> > user. Example: a middleware that sets request.user based on the
> > current session.
>
> I think convenience methods are nice and all, but we should be careful of
> making "The Registered User(tm)" too much of a baked-in concept. Ian Lewis
> made a great point a few weeks ago: There are domains in which it is
> frankly inappropriate for various authenticated users to mix in the same
> database table with the same uniqueness constraints. Maybe you run a
> medical record management site, and some of your users are administrative
> staff and doctors, and some are patients. Sure, you could manage this by
> having a unified model containing everything, and carefully validating with
> an "is_doctor" field the way contrib.admin handles "is_admin," but it might
> be more appropriate to have separate models. It becomes much easier to
> express authorization constraints such as, "As a hospital administrator,
> Ms. Sally Johnson is authorized to view the patient list of Dr. John Smith,
> but *absolutely not* his record as a patient himself," or "Patients like
> Dr. John Smith can be authenticated via Facebook Connect, but doctors need
> to be authenticated via our internal LDAP." You can have login ModelForms
> for doctors that log in to doctor records and the Django admin site, and
> login ModelForms for patients that let them view their own records through
> the frontend.
>
> Obviously supporting multiple user models isn't something that should be a
> priority for Django, but locking people out of the choice seems unwise,
> when we can get the option "for free": just let authentication backends
> return any authenticated object at all to add as request.user. Python's
> duck typing will get you the rest of the way, except for those persnickety
> tables that absolutely must have a specific concrete table to foreignkey
> on. We already do something similar for AnonymousUsers, exposing a common
> interface at request.user that isn't backed up by the canonical User table.
> Generalizing that is A Good Idea in my opinion.
>
> Anyways I look forward to seeing how this progresses. I'd love to be a part
> of making this happen. Would you like me to turn my work on breaking up
> auth.User into reusable chunks into a ticket on trac? I think it makes
> sense to merge no matter what we decide on for specific settings and access
> mechanisms to developer-defined users.
>
> Best,
> Alex Ogier
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
