@Luke: A simple is_active check with return False will also do so for the AnonymousUser.
@Łukasz:That's up to the developer of the backend I think. But with that you could disallow logged in users from going to the registration page for instance. (I know not a great example, but just to show the point) @Alex: Thanks for providing the example of reusable applications, that's is the best example of why we need this. On Jan 19, 8:23 am, Gert Van Gool <gertvang...@gmail.com> wrote: > @Noah, You could also look at it as what a AnonymousUser can't do on > some objects (while it's possible on others). > > -- Gert > > Mobile: +32 498725202 > Web:http://gert.selentic.net > > 2010/1/19 Noah Silas <n...@mahalo.com>: > > > > > I'm not certain I understand - if anyone can perform some action, what's the > > point of protecting it with a permissions check? > > ~Noah Silas > > > 2010/1/18 Łukasz Rekucki <lreku...@gmail.com> > > >> 2010/1/18 Alex Gaynor <alex.gay...@gmail.com>: > >> > On Mon, Jan 18, 2010 at 3:55 PM, Jannis Leidel <jan...@leidel.info> > >> > wrote: > > >> >> Am 18.01.2010 um 22:26 schrieb Luke Plant: > > >> >>> Hi Harro, > > >> >>>> Hmm I guess I'll just have to keep on hacking django then.. > >> >>>> because that 1% case is something I keep running into for every > >> >>>> project in one way or another. > >> >>>> And if it was designed for most apps, why was the row level > >> >>>> permission bits added? It's useless without simply always being > >> >>>> able to call request.user.has_perm('permission', obj) > > >> >>> Despite a slight overstatement in that last paragraph, your argument > >> >>> seems pretty good to me. The whole point of these methods is to allow > >> >>> custom backends to implement their own logic, so obviously it is > >> >>> pointless to arbitrarily limit it. > > >> >>> The only downside is that custom backends need to be able to cope with > >> >>> anonymous users being passed to the has_perm methods, but that is > >> >>> already well catered for with the is_anonymous() method. It is also > >> >>> better to make this change before 1.2 lands, otherwise we have a > >> >>> slight backwards incompatibility if we wanted to do it in the future > >> >>> (backends could break if they unexpectedly got an AnonymousUser > >> >>> instead of a User). > > >> >>> Anyone got a good reason reason why this *shouldn't* go in? I'm +1 on > >> >>> committing. > > >> >> Hm, I don't see a good argument to allow anonymous users to have a > >> >> permissions, to be honest. Anonymous users are by definition not > >> >> authenticated. Giving them more meaning by being able to grant them > >> >> permissions doesn't make them anonymous anymore, right? > > >> >> Also, before adding those hooks to the ModelBackend, AnonymousUser > >> >> never returned True when asked if it has a permission or not. Why > >> >> should it > >> >> now? > > >> >> Jannis > > >> >> -- > >> >> 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. > > >> > I think the best argument in favor of it is using permissions with > >> > reusable applications. Say I have a wiki application I write, I don't > >> > know whether anonymous users should be able to edit pages, I could > >> > make it a setting, but that's ugly. Instead the natural thing to do > >> > is ask the auth backend and let the developer implement it however. > > >> This argument convinced me to like this idea :) My only concern is > >> that, a newly created user could have fewer permissions then an > >> anonymous one. I can't think of a situation where this would be > >> useful. So maybe all other users could actually inherit those > >> "anonymous permissions" ? > > >> > Alex > > >> > -- > >> > "I disapprove of what you say, but I will defend to the death your > >> > right to say it." -- Voltaire > >> > "The people's good is the highest law." -- Cicero > >> > "Code can always be simpler than you think, but never as simple as you > >> > want" -- Me > > >> > -- > >> > 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. > > >> -- > >> Łukasz Rekucki > > >> -- > >> 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. > > > -- > > 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.
-- 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.
