On 18/03/2012, at 12:19 PM, Ian Lewis wrote: >>> 5. Basic username (or email)/password authentication can be provided. >>> The app has a base user class from which a basic abstract user with >>> username/password is defined. This can implement setting passwords >>> properly and provide forms etc. >>> 6. Multiple user models can be defined (Like say for normal users and >>> affiliate users or admin users). If one wants to create a project >>> currently with a separate user model, none of the machinery in the >>> auth app can be used. >> >> Sure you can -- you have a base User, and then subclasses to get AdminUser >> and NormalUser -- both of which are effectively just another type of >> UserProfile. > > I meant one that was a completely separate concrete base model. The > current auth forces you to take along with you all the fields on the > User model.
In the current setup, then yes, you need to bring along all the fields of the current User mode. But if we're refactoring so that you can have a pluggable User model, then "all the fields" can be a minimal subset if you want it to. >> >> How does this address the issue of reusable apps referencing User? Let's say >> I write a comments app, and want an Author field. I need a ForeignKey to >> "User". But I can't have a foreign key to BaseUser, because it's an abstract >> class. How do I define my Comment model in such a way that it can reference >> a generic "User"? >> >> It seems to me that the solution you're proposing requires the LazyFK and >> app-refactor infrastructure I've described in order to be useful in the >> general case (not that I'm complaining, mind -- just pointing out that our >> two proposals are complementary :-). > > This is a bad example for showing how that works. I just wanted to > illustrate how you would make your own User model. In the case where > you want a foreign key to User you can import the default user model > from newauth.models as User much like you do with the current django > auth app. > > See: http://ianlewis.bitbucket.org/django-newauth/third_party.html I've had a chance to take a closer look at your code, so I've got a clearer idea of how your setup works now. If you'll permit me the liberty of reducing all your hard work into a set of bullet points, here's what I see: * Middleware, views and backends that mostly mirror Django's existing auth implementations * An abstract base class with a minimum feature set. No argument that this is the right approach. * No permissions or groups. I appreciate that this is probably because you haven't got a need for them; but from Django's perspective, we need to have those pieces defined, because it's required for admin. However, in whatever we do, we should follow your example and maintain a clear separation between the two concerns (e.g., define the fields required for authentication separately from the fields required for authorization). * A mechanism for plugging in (and finding) a concrete user class. Although the names are a bit different, the general plugable solution you've isn't that far removed from what has been proposed in the past with a AUTH_USER_MODEL setting (or similar). This is essentially what #3011 originally proposed, what Clay McClure has proposed in the branch he posted, and what contrib.comments does. The biggest argument against this approach is that it introduces a circular dependency between models.py and settings. When Django starts up, one of the first things it does is load the settings module; this populates INSTALLED_APPS, which in turn imports each the models.py for each app. If models.py imports settings, you can get into some interesting territory. Unfortunately, it's also one of those things that tends to work *most* of the time; it's only the edge cases where you get bitten. The upside to using the AppRefactor+LazyFK approach that I've described is that it breaks this dependency. The App object defines all the configuration parameters, and is loaded when INSTALLED_APPS is configured; models.py can be imported without reference to the App; and the final model step of configuring model references can be performed with an app cache that is known to be fully populated. It also has the benefit that it provides a general solution to the common problem, so that other app writers don't have to reinvent the same "find app/find model" wheel when faced with a similar plugable problem. * One very big new feature -- the ability to have multiple User models in the same project. This is the one controversial part of your proposal, from my perspective. In every situation I can think of, I can only see it being an annoying -- e.g., having an admin username that is different from my normal user username; duplicating foreign keys to two different types of User object, and so on. If it wasn't for this last point, I'm reasonably certain that your newauth could be achieved through a series of progressive enhancements to the existing auth app. I'm sure you haven't done this just for giggles -- so what is the use case for this feature? 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. 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.
