How is the final approach chosen ? From: Alex Ogier Sent: Friday, April 06, 2012 2:31 PM To: django-developers@googlegroups.com Subject: Re: auth.user refactor: the profile aproach
Tai, read https://gist.github.com/2289395 for a summary of many reasons why I think profiles are a bad idea, and unifying multiple profiles is an even worse idea. Best, Alex Ogier On Fri, Apr 6, 2012 at 6:15 AM, Tai Lee <real.hu...@mrmachine.net> wrote: Alex Ogier, Is it really better to require users to create their own User model that behaves like an admin user, instead of just shipping with a self contained admin user (as a profile model) without the auth component? If the auth app was purely a stub to connect different profiles and authentication systems from different apps (or the project), but doesn't actually define any identity or authentication or profile models itself (not counting base abstract classes), isn't that effectively achieving the separation that you want? Being able to use admin without the current cruft in auth or with any completely different authentication credentials, and similarly using any other pluggable app without any cruft needed by the admin. In any case, I don't think it will actually be possible to use the admin or any other pluggable app that relies on the concept of a central user who might access to multiple apps (instead of every app having its own users and auth) without *an* auth app and a central User model. Like Adrian, I don't actually use the User model for auth or identity (name, email, etc.) anymore. But unless you have authored *all* the apps in your project and they know how to talk to *your* User model, you still need a User from Django, because that is what all 3rd party pluggable apps will need. If I want to use any 3rd party apps that use the central user, I will still need to create a Django User and fake or sync the that are only there for the admin, even if I don't use the admin. If you still require swapped in User models to assume a minimal interface and fields, people will still have this problem. This is why I think the central User should not contain any auth or identity data, so there is no cruft required only for apps you may not even be using, and so you are not tied to any particular auth system. Cheers. Tai. On 06/04/2012, at 3:44 PM, Alex Ogier <alex.og...@gmail.com> wrote: I think this proposal will make more sense if people stop thinking "If someone wants to use contrib.auth, then why do we need another crufty interface to swap out auth.User?" Instead think of someone who wants to use contrib.admin but not be stuck with contrib.auth. The point of this proposal isn't to make contrib.auth larger and better, it's to make it unnecessary. A lot of people find contrib.auth's models unsatisfactory. Adrian Holovaty stated that he hasn't used auth.User for several years. When you have a complex site with multiple authentication methods and requirements that don't fit django's idea of a user, it stops being worth it to bend yourself to django's will. The problem is that contrib.auth and contrib.admin are currently intimately linked. This proposal's purpose is to give an official way to break these two apart. I don't know of a single framework out there besides Django that ships with a fixed model for its users. The reason is that authentication and identity are radically different for every site so it's tremendously important to support whatever people decide to do, and not force decisions on them. So, stop thinking just in terms of contrib.auth.models.User. If you're already using that with a profile and it's all working fine, then this change isn't for you. This is for everyone who just wishes auth.User would go away without totally borking admin. Respectfully, Alex Ogier On Apr 6, 2012 1:21 AM, "Donald Stufft" <donald.stu...@gmail.com> wrote: Nothing about this proposal prevents this. And in that case, no those 2 apps would not be able to be used together. But this is hardly the first time that 2 apps cannot be used together. because of choices made like that on the app owner. On Friday, April 6, 2012 at 1:18 AM, Harris Lapiroff wrote: I very much share Tai's concerns about the swappable user model introducing incompatibilities. Imagine two apps, each of which requires an "age" attribute on the user model. But suppose one of those apps expects age to be the number of years since that user's birth and one of those apps expects the age to be the number of years since the user registered for the website. The user model must provide the same attribute to both apps, but it is supposed to have a different value for each app. A developer will be unable to use these two apps together without patching one of them. A bit of a contrived example, maybe, but I can imagine this same-name-different-purpose issue coming up over and over again, making otherwise pluggable apps incompatible with each other. I think we should go with a pared down user model and allow each app to manage whatever data it needs on each user through profiles and signals. Developers will end up with some data duplication, but I think that is preferable to confusion about the source and purpose of data. Profiles are essentially a way for each app to namespace its own data and I think that's a good thing. Harris -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/p4jhylEp3x8J. 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. -- 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 mailto:django-developers%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en. -- 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. -- 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 mailto:django-developers%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en. -- 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. -- 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.
