I'll pick this topic up for some changes I think Django needs. Please read the summary between the "="-line, if you don't have the time to read the whole mail. Perhaps it will get you interested in reading the rest. ;-)
As far as I can see there are different approaches to improve this (which have been posted in this discussion already): * http://code.djangoproject.com/ticket/3011 Split auth-Module into two parts: Authentication and User-Model -> AUTH_USER_MODULE defines which User-Model to use * Auth-Backends, in the current SVN -> The User-Model still is in your Database I think the best way in solving this is to combine this two: * The User-Model gets its own application, including: - models.py - backends.py - special views or perhaps all of them (didn't read the whole code, includes forms.py) - create_superuser.py * The auth-Module morphs into a authentication-framework, that can use the User-Model, but is not bound to it (other model can be used by changing AUTHENTICATION_BACKENDS), includes: - __init__.py - middleware.py The only difference I see, is that you need to include some "django.contrib.user"-application, if this two parts are separated in a clean way. Big advantage would be, that the admin stays usable if you change the User-Model, as it only needs to use the authorization-framework. Additionally I would merge this idea with the django-branches that try to improve permission-tests (generic-auth, per-object-permissions). More precisely it would make sense to create some permission-framework es well. I think the Ideas behind the generic-auth-branch (http://code.djangoproject.com/wiki/GenericAuthorization) are pretty nice, I like to have one function I pass an object, an user and some permission and get an result. Some additional thoughts: * To recreate the current behavior you could use the Model itself passed as the object (Article(=class) instead of article(=instance)) * I dislike the idea to be forced to register some permission-test. As the Article says it should be put into the Meta/Admin- or perhaps Permission-subclass of a Model, which would be fine or even a MUST HAVE. If some permission-framework is created I would prefer to separate the Permission-Model from the auth-Application (or User-Model/user-application). It would be nice to create two default-systems for permissions as separate applications: * Model-Permissions like used now * Row-Level-Permissions like proposed The permission-framework should be able to use this two systems concurrently. Each model (or application (as a default)) should be able to choose which permission-system to use (or even use more than one). Perhaps separation the permission-framework from the auth-framework would be even nicer (you can use the auth-system, but use your own permissions-system). Also I don't like putting some permission-system into the models(.py). This should only be used to define your models and not for some kind of permission-checks ================================================================= To summarize: I think the User/Group/Permission-Model should be separated from the auth-framework. You should be able to choose other models using the backends-config or similar. Also there should be created some generic permission-framework, close to generic-auth. This framework should not rely on any model. Two default-implementations should be created (model and row-level). ================================================================= I think splitting the auth-application into multiple parts and creating some basic frameworks that can be used to do such tasks is really important. Without this the auth-framework will get bigger (just imagine the generic-auth-merge), but instead of getting more flexible it will only solve more specific problems. And if the admin (or any other application that needs authentication) should be usable, even if someone is not able to use the provided authentication-system and implements his own, there needs to be some basic framework without any drawbacks (auth-backends are there, but they pull the whole User/Group/Permission-Models with it). I would like to contribute creating this, if someone is interested. Perhaps the best place to start (or even work if Joseph Kocherhans likes my plans?) is the generic-auth-branch. I believe such a system should be ready with Django 1.0. Otherwise the whole auth-System (and with it the admin) is not as usable as it could be. And even better, it would simplify managing the auth-system as a whole (only small apps, that implement, provide or use some API). Greetings, David Danier P.S.: Sorry about the missing "In-Reply-To"-Header, I just joined this list. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
