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 Sent: Tuesday, April 03, 2012 10:28 AM To: 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> 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. 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.
