On Thu, Mar 15, 2012 at 5:53 AM, Danny Adair <danny.ad...@unfold.co.nz> wrote:
Hi Danny, > I'm sorry I don't know if I like that. I hope I understand correctly > what you're doing, and that my criticism is seen as constructive. > Thanks for reviewing the code and providing feedback. > This sells itself as "pluggable auth" but really only provides the > originally requested auth by email, and I don't see how it could go > from there, i.e. what else would be possible (in regards to auth). > Pulling username and email out of (Base)User and then bringing one or > both of them - and the logic of which to check - back in, is not > really a pluggable auth. > It's "pluggable" in the sense that you could write a User model with whatever fields, methods, and attributes best suits your application. You aren't required to extend BaseUser—I only added that abstract class because I figure that most deviations from the stock User won't be that drastic, and it's convenient to be able to inherit from a model that has most of what you need already. It's the mixing of profile and information relevant to authentication > (and authorization - is_staff?) that's another problem of the existing > User model, and this is where this approach allows for dangerous > developments. > My dissatisfaction with the stock User model has less to do with the the fact that it combines authentication credentials and profile information in a single model, and more to do with the fact that it's hard to work around the stock User model if it doesn't meet your needs. The stock User model is the simplest thing that could possibly work—and indeed it does work, for most projects—but it's also one of the few components of Django that isn't configurable or replaceable. I can provide a custom ModelBackend easily enough, and a custom AuthenticationForm, but I'm always stuck with the auth.User model. We could debate for a long time (in fact, we have—the ticket was opened five years ago) what constitutes a proper User model, but may never reach a conclusion. Some will want to separate authentication from identity from profile, others will want to keep it simple. It's not clear to me that there's a "correct" User model, just as there's not a "correct" blogging application. So, rather than offer specific improvements to the stock User model, I aim to provide a means for developers to use their own User model, should they need to do that. > What about first_name and last_name? Why can't a pluggable auth dump > those from the User model? And certainly an "auth" should get to have > a say about "password". > Certainly, you could write a pluggable User model without first_name and last_name fields. Some have requested a User model with a simple "name" field. You could do that. It may not work in the admin, unless you define a first_name property, but your User model should work with a great many applications. The same is true for the password field: write a User model without it, if you'd like. That should work almost everywhere, even in the admin, so long as you provide your own UserCreationForm and UserChangeForm, and your own backend that handles authentication another way. And then... there's not much left anymore in that (Base)User model, > right... (GSoC: "reducing the user table to little more than an > identifying primary key") > Just to be clear, the BaseUser that I've proposed is there for convenience. It is not required. We could pare down BaseUser even more, but I suppose there will always be some disagreement about what should be the minimum set of fields and methods on a User model. I avoid that debate by saying that BaseUser isn't required—inherit from it, or don't, it's your choice. Some developers may want a User object that is just a primary key. They may have factored authentication and identity out in a way that is much more flexible (and much more complex) than the stock User model. That should be possible—and with pluggable auth apps, it is. Ok email auth problem solved. But now there's a simple way of > providing any User model I like, so first thing I'm going to do is to > bring in what I think the User should look like i.e. use the "auth" to > define what really is a "profile". And so will lots of projects. "The > User model needs a username for this app to work". "The User model > needs a timezone for this app to work". etc. > I'd like to see a later, "proper" auth.user that can undo that chaos. I don't know that I would call that "chaos". For many applications, it makes sense to have a simple User model with some profile data. I might not want to incur the extra JOIN or SELECT required to fetch a separate UserProfile object. Maybe it makes sense to store some profile attributes (display name, for instance) with the authentication credentials. Maybe it doesn't make sense to store email address there—what if I have several email addresses?—or timezone—what if I travel? There isn't a one-size-fits-all solution, but I think we can at least give developers a way to use a User model that fits their needs. Cheers, Clay -- 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.
