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.
