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.
