On Saturday, March 17, 2012 at 1:59 AM, Russell Keith-Magee wrote:
>
> On 17/03/2012, at 12:53 AM, Jacob Kaplan-Moss wrote:
>
> > Hi folks --
> >
> > This discussion of user authentication by email is getting pretty nasty;
> > can we start over? I know there's a lot of quite legitimate frustration
> > here, but we really need to drop the personal stuff and focus on the
> > problem at hand. I want to move this forward quickly, and I can commit to
> > spending some time on it in the coming weeks, but I'm going to lose
> > interest faster than than you can believe if the tone doesn't improve.
> > Please: keep it professional, and focus on the tech. I promise things'll go
> > smoothly if we all do.
> >
> > As I see it, there's two basic approaches we could take:
> >
> > 1. Incremental improvement: fix the most glaring issues with auth.User
> > (starting with email addresses for login, clearly), and generally improve
> > things a bit at a time. Once User's in a state where we're happy, move on
> > the rest of the auth app -- again, a bit at a time. This approach would see
> > the largest issues fixed more quickly, but would probably do so at the
> > expense of code quality (e.g. requiring a one-off solution to schema
> > migration of the User model) and would delay a more sweeping reform until
> > later.
> >
> > 2. Complete improvement: recognize that the auth app is fundamentally
> > flawed, and mercilessly refactor/replace/rewrite it, all in one go. The
> > hypothetical results here would be better -- a modern auth system
> > unencumbered by the decisions we made in 2005 -- but this would take far
> > longer, and would block on things like the app refactor and schema
> > migrations.
> >
> > There's also a middle-ground proposal from Clay: make the auth app
> > swappable, thus making it possible for *users* to replace the auth app
> > while leaving time for us to make either incremental or complete change, as
> > we see fit.
> >
> > I think we need to come together and agree on an approach before we move
> > forward, so I'd like to see some concrete proposals for each of these
> > approaches. Since all options have merits and since I think it's unlikely
> > we'll find consensus I'm prepared to make a BDFL ruling here. So if you
> > feel strongly about one approach or another, please write a concrete
> > proposal and post it here or on the wiki. I'll look these over -- and also
> > review Clay's branch -- and (again, baring consensus) make a ruling next
> > week.
> >
> > Just so my biases are clear: normally I'd lean more towards the
> > completionist stance, but in this case I haven't seen an actual proposal to
> > completely replace auth. Further, I think the fact that it's blocked on
> > *other* pretty hairy issues means it'd be unlikely to see that much action
> > that quickly. I'm also somewhat opposed to the "pluggable auth" idea since
> > I think it dilutes the utility of having built-in auth. In other words, if
> > we're going to make auth up to users, why not just get rid of the built-in
> > auth altogether? So I'm leaning towards an incremental improvement
> > approach, but only if I can see a concrete proposal that articulates what
> > to change, and deals with the backwards-compatibility issues in a
> > not-too-ugly way.
>
> Ok - I've been keeping quiet on this; partially due to the same tone issues
> that you've described, but also because I don't have a huge amount of spare
> time at the moment, and I don't want to be the person who makes a bunch of
> promises (expressed or implied) to work on something and then can't deliver
> on those promises.
>
> My biggest concern is that the middle-ground proposals that are on the table
> are implementing a workaround for a problem when the starting point of a
> long-term solution won't require that much more effort.
>
> IMHO, rather than implement a bunch of settings to introduce an
> auth.User-specific solution, we need to do two things:
>
> * Merge the app-refactor from GSoC 2010.
>
> This has a whole bunch of long-needed awaited benefits -- reliable hooks for
> app startup, configurable app labels, predictable module loading, amongst
> others -- but the one that matters for the purposes of auth.User is that it
> allows Apps to be treated as items that need to be configured as a runtime
> activity. In this case, we need to be able to specify, at a project level,
> which model is your "User" model in the auth app.
>
> * Add the concept of a LazyForeignKey.
>
> LazyForeignKey is a normal foreign key, with all the usual foreign key
> behaviors; the only difference is that the model it links to isn't specified
> in the model -- it's a configuration item drawn from an application
> configuration. So, ForeignKey('auth.User') creates a foreign key to
> django.contrib.auth.User; LazyForeignKey('auth.User') asks the auth app for
> the model that is being used as the 'User' model, and creates a foreign key
> to that. This isn't a huge body of work -- it's just a matter of slotting
> into the existing model reference resolution code (which is something that
> the app refactor cleans up).
>
> What are the benefits of this approach?
>
> * It solves the general problem, rather than just focussing on auth.User.
>
> The broad idea of defining behavior against an interface, rather than a
> concrete model, is hardly new; auth.User is just the most obvious
> manifestation in Django's problem space. It doesn't take much work to find
> other examples: contrib.comments has an analogous "choose the comment model"
> problem (solved in it's own bespoke way). It wouldn't take much of a survey
> to find a whole lot of similar examples.
>
> If we just add settings to make auth.User configurable, we don't address the
> analgous problems of any other app.
>
> * It's completely backwards compatible.
>
> If you've got an existing app with normal ForeignKeys to auth.User, the app
> will continue to work, without any migrations, as long as the rest of your
> project uses auth.User. It will also co-exist with any configurable app that
> is configured to use auth.User as the user model. It will only fall down if
> you have a configurable app that uses a different User model (i.e., you can't
> use a new feature without ensuring all the parts you need support the new
> feature).
>
> * It's got a relatively simple forward migration path for app authors
>
> For most of the use cases being discussed in this thread (e.g., make email
> max_length=254), just replace ForeignKey(User) in your app with
> LazyForeignKey('admin.User'), and it should work without any problems.
>
> More specifically, you just need to be aware of the contract that you expect
> a User model to honor. We can help out here by clearly documenting the
> "admin" User contract (and doing a light refactor of admin as required to
> adhere to use that contract -- e.g., replacing uses of user.username with a
> "get_identifer()" type method). This would have the effect of setting a
> defacto standard for what you can expect to find on a User model.
>
> * It solves the immediate problem ...
>
> As I see it, the immediate problem is that developers want to be able to
> modify the base requirements of auth.User. There may well be people who want
> to completely change contrib.auth, but for the moment, the 90% case can be
> solved by modifying max_length or setting unique=True on the email field,
> and/or removing the username field. The rest of auth.User is fine, at least
> for now.
It doesn't really solve the immediate problem though. It does technically but
it also requires every single app that uses auth.User to update itself
before you can use it which makes it less useful.
>
> * ... without making a rod for our back long term ...
>
> Once we have a configurable Auth app, we can work out the details of what
> else needs to be configured, and how, in order to satisfy other use cases
> that are presented. However, we'll have tackled the hard part -- getting a
> framework in place for adding configuration points -- as part of the initial
> effort.
>
> * ... or introducing a bunch of settings.
>
> 'nuff said. In fact, it would potentially allow us to *deprecate* a bunch of
> settings (e.g., REDIRECT_FIELD_NAME, LOGIN_URL) and make them application
> settings.
>
> Yours,
> Russ Magee %-)
>
> --
> 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.
