I just thought of another way this might be possible: signals. Just add them to the anonymous user functions. The signal would get passed a variable holding the currently returned result, and then returns it. That way you can hook into it and modify the result without breaking the current behaviour.
On Jan 20, 8:49 am, Harro <hvdkl...@gmail.com> wrote: > class User(models.Model): > permissions = models.ManyToMany('Permission', > through='UserPermission') > > class UserPermission(models.Model): > user = models.ForeignKey('User', blank=True, null=True) > permission = models.ForeignKey('Permission') > > class AnonymousUser(models.Model) > > @property > def permissions(self): > return UserPermission.objects.filter(user__isnull=True) > > On Jan 19, 10:12 pm, Luke Plant <l.plant...@cantab.net> wrote: > > > On Tuesday 19 January 2010 16:23:32 Harro wrote: > > > > And I guess making it truely awesome would require permissions for > > > anonymoususers in the default backend too. :( > > > > If I have timeI'll see what I can come up with. > > > Ticket #9444 [1] is about that, and it had a lot of opposition. > > > It is hard or very hacky for the provided auth backend to support > > object-level permissions for anonymous users, because there is no > > obvious place to store permissions. But making it *possible* for > > custom auth backends to do this is a different matter, and is all we > > should be aiming for I think. > > > Now for some out-loud thinking about the consequences of this patch: > > > Once you make it possible, it is likely that the authors of re-usable > > apps will want to depend on this capability. That means that writing > > custom auth backends would now be much more common. The auth backend > > already covers both authorization and authentication, but if the > > authors of re-usable apps are encouraged to depend on it to handle > > authorization even for anonymous users, then it will be much more > > commonly required. > > > I don't see this as necessarily a problem, it's just a shift in > > direction. The more I think about it, the more it seems that > > authorization questions really need to be decided on a per-site basis, > > and this mechanism is a good place to do it. (Some people object to > > mixing authorization and authentication, but it's a bit too late to > > fix that, and in practice full decoupling is tricky and overly- > > complex). > > > I've thought through some other scenarios, such as having multiple > > types of login (on one site I use 'User' in the normal way for people > > with access to the admin, and a completely separate 'Member' model for > > completely different type of access), and I can see ways for all of > > these to work, although you might have to supply a custom > > AuthenticationMiddleware, and your own User objects which have the > > same interface as the supplied one. > > > The other consequence of app authors depending on this is that apps > > might become more restrictive by default, and harder to "open up". > > Whereas before you would allow an anonymous user to, say, write a > > comment, or had a single setting to control it, now you will just > > delegate to the auth backend, which by default has no permissions for > > anonymous users. Again, I don't see this as particularly bad - the > > amount of spam these days means it's probably helpful to have things > > locked down by default. > > > Regards, > > > Luke > > > [1]http://code.djangoproject.com/ticket/9444 > > > -- > > "Pretension: The downside of being better than everyone else is > > that people tend to assume you're pretentious." (despair.com) > > > Luke Plant ||http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.