Like Carl I was +1 on Profiles and I'm now leaning towards the Swappable User
Models.
It's explicit (it only changes when you change the USER_MODEL setting).
It's Duck Typing which is Idiomatic in Python. ("This app depends on a user
model that defines ``email`").
If you wish to add OpenID you'd make your UserModel quack like an OpenID Duck,
as well as Quack like a Username/Password Duck.
On Tuesday, April 3, 2012 at 4:34 PM, Daniel Sokolowski wrote:
> Alex I have looked over your proposal and I agree on both your concerns with
> LFK, and Jacob’s approach; however I still find the profile approach is the
> most flexible solution.
>
> Correct me if I’m wrong but both LFK or a swappable user model approach like
> your fail to address issue of extensibility. If today my project is
> authorizing with username and password and tomorrow I wish to add OpenAuth
> then my User model is replaced, whereas with Jacobs approach I add another
> profile model, yes? What about auth apps, you could only use one, with
> profiles many could co exist; one for Facebook, Twitter, etc.
>
> Your point 4 claiming it’s undiscoverable is not entirely true, AUTH_PROFILE
> setting can be examined just as apps examine INSTALLED_APPS settings at run
> time. Your point 2 that being able to change the functionality so quickly is
> actually superior in my mind, it’s a lot more work to do a schema migration
> then the creation a of new profile table. Points 5 and 3 are good points
> and remind that there is no perfect solution to new auth.
>
> To sum up I am curious to know how your approach handles additional user data
> and authorization schemes.
>
> From: Alex Ogier (mailto:alex.og...@gmail.com)
> Sent: Tuesday, April 03, 2012 10:28 AM
> To: django-developers@googlegroups.com
> (mailto:django-developers@googlegroups.com)
> Subject: Re: auth.user refactor: the profile aproach
>
>
>
>
> Hi developers,
>
> I have written up a little bit about the alternate proposal that I made a
> while ago, Solution 2a from
> https://code.djangoproject.com/wiki/ContribAuthImprovements
>
> In addition to other arguments, there is a point-by-point breakdown of what I
> feel are the weaknesses in Jacob's proposal.
>
> You can find it at https://gist.github.com/2289395
>
> Best,
> Alex Ogier
>
> On Mon, Apr 2, 2012 at 8:35 PM, Jacob Kaplan-Moss <ja...@jacobian.org
> (mailto:ja...@jacobian.org)> wrote:
> > Hi folks --
> >
> > I've written up a proposal for how *I* would like to address refactoring
> > auth.user: https://gist.github.com/2245327.
> >
> > In essence, this does two things:
> >
> > * Vastly "prunes" the required fields on auth.user. The only things left
> > are an "identifier" (which could be username, email, url, uuid, whatever),
> > and a password.
> > * Introduces a new "profile" system that provides a way to contribute extra
> > related fields. Multiple profiles are supported, along with some syntactic
> > sugar for dealing with multiple profiles in a reasonably reusable way.
> >
> > And that's about it. I'm deliberately trying to find a middle ground
> > between "do the minimum to allow people to move on" and "throw out and
> > rewrite django.contrib.auth entirely". I'm not expecting everyone to be
> > thrilled by this idea, but I'm hoping that this is "Good Enough" for almost
> > everyone.
> >
> > For more please see the document. Please do try to read the whole thing:
> > I've had a few rounds of feedback incorporated already, and there's even an
> > FAQ at the end.
> >
> > I'm not using BDFL fiat here, at least not yet. This is a proposal, and I
> > very much want to hear feedback, objections, and alternatives. I'm
> > particularly interested in hearing from people who've got complicated auth
> > needs and think this absolutely won't work for them.
> >
> > I *have* reviewed all the other proposals and I'm between -0 and -1 on all
> > of them. This means that if you don't like my proposal, you'll probably
> > have to come up with a complete *new* idea to have any chance of getting my
> > vote.
> >
> > Thanks!
> >
> > Jacob --
> > 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
> > (mailto: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
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> (mailto: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
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> (mailto: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.
