> I'm thinking of different applications needing some > authentication-system. [...] you will > end up in having different systems in every application (in the worst > case, think of third-party-applications). [...] > If instead every application uses some generic calls to get the > user-data, manage the session (here this is done already) and handle > permissions this gets simple. The application does not need to know > which model is behind the user, it can count on get_absolute_url() and > __str__() to use it most of the time. [...] So I > would at least separate these two (auth-api and user-model).
After rethinking this I believe this will not work out and AUTHENTICATION_BACKENDS will not help either, but make things even worse (more complicated and unusable). The real problem with own user-systems is, that you cannot use a foreign key anymore. You could use something like it is done in the session, but this is not really nice (save user + user-backend in the database). You can see a workaround for this problem when reading the LDAP-Auth-code (http://www.carthage.edu/webdev/?p=12). The backends-framework allows the user to return any user-object, but instead of doing so a copy is created in the database to get things right (as the comment says: to get the permissions working). Saving some data into the database is not what I think is wrong here (even if it would be nice to be able to skip this, too), but using the existing user-model only because no foreign-keys are working without it really seems wrong to me. So, I recommend adding some configuration-variable to set the authentication-system. You should only be able to set one system here (no backends). If the user wants multiple authentication-backends this can be done using one system, that does this for him (like the backends now). BUT: the new API should only use _one_ user-model. So you are able to use a foreign key with it (With multiple backends you need some translation-table). Perhaps it is enough to be able to set the user-model inside the settings and use UserManager-methods to do the rest (this is what I try to do in the example below). The backends-system really make things more complex, I don't think this will improve development. Note: You could of course implement some Model that does this translation mentioned above as an enhancement to the current backends-system. But as most people don't need multiple backends I would prefer keeping things simple and do backends as some possible authentication-system, that might be used, but no one is forced to. And even when doing this with the current system, it is not ready in the current state and really needs this enhancement, I think. Don't get me wrong. I like the idea behind having multiple backends (and really was excited when reading the current SVN-code), but after trying to use it in my own application I discovered, that things get really messy with foreign-keys and even request.user (you cannot use request.user without checking it's type, because some backend could not return the user-model you expect). Examples (hint: this is all very simplified, only to show what I mean): settings.py: ----------8<--------------------------------------------------------- AUTH_USER_MODEL = 'foo.user.models.User' --------------------------------------------------------->8---------- django/contrib/auth/__init__.py: ----------8<--------------------------------------------------------- # this function could be put into some core-api, too (might be better) get_authentication_model(): i = path.rfind('.') module, attr = path[:i], path[i+1:] try: mod = __import__(module, {}, {}, [attr]) except ImportError, e: raise ImproperlyConfigured, 'Error importing authentication backend %s: "%s"' % (module, e) try: model = getattr(mod, attr) except AttributeError: raise ImproperlyConfigured, 'Module "%s" does not define a "%s" authentication backend' % (module, attr) return model --------------------------------------------------------->8---------- foo/user/models.py: ----------8<--------------------------------------------------------- class UserManager(models.Manager): def authenticate(**credentials): pass def login(request, user): pass def logout(request): pass class User(models.Model): objects = UserManager() --------------------------------------------------------->8---------- foo/blog/models.py (some usage example): ----------8<--------------------------------------------------------- class Post(models.Manager): user = models.ForeignKey(auth.get_authentication_model()) --------------------------------------------------------->8---------- usage: ----------8<--------------------------------------------------------- # auth u = auth.get_authentication_model().objects.authenticate(foo=bar, bar=foo) # login auth.get_authentication_model().objects.login(request, u) --------------------------------------------------------->8---------- Multiple backends (foo/user/models.py): ----------8<--------------------------------------------------------- class UserManager(models.Manager): pass # like above class User(models.Model): objects = UserManager() user_id = models.IntergerField(...) user_backend = models.XxxField(...) def _get_backend(): return load_backend(self.user_backend) def _get_user(): return self._get_backend.get(pk=self.user_id) user = property(_get_user) --------------------------------------------------------->8---------- As you see, this makes the backends-system obsolete (sorry), but keeps its flexibility while making things simpler for application-developers. For the permissions-system I would do similar. (One configuration-directive, some API thats fixed but allows model- and row-level-permissions) If you are interested I could try to contribute some code, too. ;-) Greetings, David Danier --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
