Re: auth.user refactor: the profile aproach

How is the final approach chosen ?

From: Alex Ogier 
Sent: Friday, April 06, 2012 2:31 PM
To: [EMAIL PROTECTED] 
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 [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.


      -- 
      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 mailto:[EMAIL PROTECTED]
      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 [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.

  -- 
  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 mailto:[EMAIL PROTECTED]
  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 [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.

-- 
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.