Re: AnonymousUser has_perm/has_module_perms function check authentication backends
> I would then write a simple decorator which checks the backends for > that flag to determine if we should do a login_required or has_perm > check. > Because a real pluggable app would want to support both :) No it wouldn't. It would either use the permission system or the decorator for login_required (which would require an extra field on the model…). The checking for `supports_anonymous_users` in 3rd party apps doesn't make sense as backends which supporting it, don't necessarily need to provide a permission system for that app… (For one system I take the common permissions from ldap and another app uses a custom in database system, all running of the same Django install) -- 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
> some documentation should also be added. + Tests The question is, whether we want `supports_anonymous_users` to go away at some point or stay forever (I would prefer if it went away and every backend had to support anonymous users; then the patch would need the usual deprecation warnings…). Cheers, Florian -- 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
Added a patch to the ticket. some documentation should also be added. [1] http://code.djangoproject.com/attachment/ticket/12557/supports_anonymous_users.diff [2] http://code.djangoproject.com/attachment/ticket/12557 -- 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
I think the `supports_anonymous_users` thing is the best and most simple solution. The anonymous user should then only call has_perm/has_module_perms on backends that have that set. I would then write a simple decorator which checks the backends for that flag to determine if we should do a login_required or has_perm check. Because a real pluggable app would want to support both :) On Jan 26, 4:01 pm, Florian Apolloner wrote: > On Jan 26, 3:19 pm, Harro wrote:> - If the default > backend always returns false for anonymous users then > > pluggable apps have to either expect some row level permission system > > is installed and used or don't check permissions for things that an > > anonymous user can access. > > Why do they have to expect a row level permission system to be > installed? The ModelBackend would always return False for anonymous, > so everything would stay as it is… > > > I think the best solution is to add anonymous user permissions as > > proposed by me a bit up, but only actually check them if a settings > > flag is set to True (with a default on False). If it's not set it will > > simply return False for anonymous users, otherwise it will check the > > permissions. > > I am -1 on that, using `supports_anonymous_users` is way better and > allows a cleaner upgrade path (as every backend will have to support > anonymous users sooner or later) -- 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
On Jan 26, 3:19 pm, Harro wrote: > - If the default backend always returns false for anonymous users then > pluggable apps have to either expect some row level permission system > is installed and used or don't check permissions for things that an > anonymous user can access. Why do they have to expect a row level permission system to be installed? The ModelBackend would always return False for anonymous, so everything would stay as it is… > I think the best solution is to add anonymous user permissions as > proposed by me a bit up, but only actually check them if a settings > flag is set to True (with a default on False). If it's not set it will > simply return False for anonymous users, otherwise it will check the > permissions. I am -1 on that, using `supports_anonymous_users` is way better and allows a cleaner upgrade path (as every backend will have to support anonymous users sooner or later) -- 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
On Tuesday 26 January 2010 12:12:23 Jari Pennanen wrote: > I read from "1.2 beta" thread that this might make it to the 1.2 > beta of Django, any status on that? Is someone trying to commit > the patches? Florian Apolloner pointed out that it had backwards incompatibility issues. I'm hoping to look at it tonight and see what I can do, probably along the lines of a 'supports_anonymous_users' attribute, like the 'supports_object_permissions' attribute. If anyone else can do a patch and let me know before 21:00 GMT, that would be great. Luke -- "The first ten million years were the worst. And the second ten million, they were the worst too. The third ten million, I didn't enjoy at all. After that I went into a bit of a decline." (Marvin the paranoid android) 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
I think so far we agree that we need to add something for anonymous users, because the added enhancement currently doesn't add enough to integrate row level permissions as they should be. The problems are: - Anonymous users should check the authentication backend for permissions, so it is possible to implement anonymous user permissions - If the default backend always returns false for anonymous users then pluggable apps have to either expect some row level permission system is installed and used or don't check permissions for things that an anonymous user can access. I think the best solution is to add anonymous user permissions as proposed by me a bit up, but only actually check them if a settings flag is set to True (with a default on False). If it's not set it will simply return False for anonymous users, otherwise it will check the permissions. That way pluggable apps decide for themselves if they want to check permissions for all users and if they do throw an error if the flag is not set. Or if they simply do it the old way by doing a login_required for the views that need logged in users. On Jan 26, 1:12 pm, Jari Pennanen wrote: > I read from "1.2 beta" thread that this might make it to the 1.2 beta > of Django, any status on that? Is someone trying to commit the patches? -- 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
I read from "1.2 beta" thread that this might make it to the 1.2 beta of Django, any status on that? Is someone trying to commit the patches? -- 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
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 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 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
oh also: It's kinda like the messages framework rewrite now supporting messages for anonymous users. 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. On Jan 19, 4:34 pm, Jannis Leidel wrote: > Am 19.01.2010 um 16:10 schrieb Luke Plant: > > > > > > > On Tuesday 19 January 2010 14:23:06 Jannis Leidel wrote: > > >>> 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. > > >> So you would implement an authentication backend specifically for > >> your wiki app to be able to check if anonymous users have the > >> permission to edit a page? How is that less ugly than a setting? > > > In that simple case, a setting might be easier, but it is ugly in the > > sense of poor separation of concerns. And it is much less flexible - > > what if the setting might depend on which page they are editing? Very > > quickly you will end up with the wiki app needing it's own permission > > system. The writer of the wiki app can avoid the whole question by > > always delegating authorisation questions to the standard mechanism. > > > I understand your concern about the auth backend assuming 'User', not > > 'AnonymousUser', but we have specifically documented AnonymousUser as > > implementing the same interface as User, and I cannot see what harm it > > would cause to allow this. > > That's a good point, and I have to admit I begin to realize that the real > culprit for me is not the backend implementation but rather the special > status of the AnonymousUser. We have to jump through quite a few hoops to > make that possible. > > 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
@Janis: I see your point,in my proposal the default model authentication backend always returns False for the AnonymousUser. That would indeed mean guest users have no access at all. But I guess you could write a wrapper that used a function specified in the settings (with a default pointing to a function in your app) that takes some arguments and based on that sees if the user is anonymous or not and then does or doesn't check the has_perm function. On Jan 19, 4:34 pm, Jannis Leidel wrote: > Am 19.01.2010 um 16:10 schrieb Luke Plant: > > > > > > > On Tuesday 19 January 2010 14:23:06 Jannis Leidel wrote: > > >>> 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. > > >> So you would implement an authentication backend specifically for > >> your wiki app to be able to check if anonymous users have the > >> permission to edit a page? How is that less ugly than a setting? > > > In that simple case, a setting might be easier, but it is ugly in the > > sense of poor separation of concerns. And it is much less flexible - > > what if the setting might depend on which page they are editing? Very > > quickly you will end up with the wiki app needing it's own permission > > system. The writer of the wiki app can avoid the whole question by > > always delegating authorisation questions to the standard mechanism. > > > I understand your concern about the auth backend assuming 'User', not > > 'AnonymousUser', but we have specifically documented AnonymousUser as > > implementing the same interface as User, and I cannot see what harm it > > would cause to allow this. > > That's a good point, and I have to admit I begin to realize that the real > culprit for me is not the backend implementation but rather the special > status of the AnonymousUser. We have to jump through quite a few hoops to > make that possible. > > 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
Am 19.01.2010 um 16:10 schrieb Luke Plant: > On Tuesday 19 January 2010 14:23:06 Jannis Leidel wrote: > >>> 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. >> >> So you would implement an authentication backend specifically for >> your wiki app to be able to check if anonymous users have the >> permission to edit a page? How is that less ugly than a setting? > > In that simple case, a setting might be easier, but it is ugly in the > sense of poor separation of concerns. And it is much less flexible - > what if the setting might depend on which page they are editing? Very > quickly you will end up with the wiki app needing it's own permission > system. The writer of the wiki app can avoid the whole question by > always delegating authorisation questions to the standard mechanism. > > I understand your concern about the auth backend assuming 'User', not > 'AnonymousUser', but we have specifically documented AnonymousUser as > implementing the same interface as User, and I cannot see what harm it > would cause to allow this. That's a good point, and I have to admit I begin to realize that the real culprit for me is not the backend implementation but rather the special status of the AnonymousUser. We have to jump through quite a few hoops to make that possible. 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
On Tuesday 19 January 2010 14:23:06 Jannis Leidel wrote: > > 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. > > So you would implement an authentication backend specifically for > your wiki app to be able to check if anonymous users have the > permission to edit a page? How is that less ugly than a setting? In that simple case, a setting might be easier, but it is ugly in the sense of poor separation of concerns. And it is much less flexible - what if the setting might depend on which page they are editing? Very quickly you will end up with the wiki app needing it's own permission system. The writer of the wiki app can avoid the whole question by always delegating authorisation questions to the standard mechanism. I understand your concern about the auth backend assuming 'User', not 'AnonymousUser', but we have specifically documented AnonymousUser as implementing the same interface as User, and I cannot see what harm it would cause to allow this. Luke -- "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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
> As you say - anonymous users are by definition not *authenticated*, > but that does not be that they are not *authorised*. Permissions is > about authorisation, not authentication, and Harro had some good > examples where you want to control authorisation for non-authenticated > users in a fine-grained way. In fact, most websites assume a certain > level of authorisation for non-authenticated users (ability to browse > certain parts of the site etc.), so this distinction is already real, > not just academic, and the patch would just make it easier to control Thanks for the explanation, but I still believe that by giving authentication backends more abilities wrt anonymous users you would effectively encourage the bad practice of putting workflow logic (e.g. "Should anonymous users be allowed to use this view?") in a backend that is specifically made for the User model. 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
Am 18.01.2010 um 22:57 schrieb Alex Gaynor:
> On Mon, Jan 18, 2010 at 3:55 PM, Jannis Leidel 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.
So you would implement an authentication backend specifically for your wiki app
to be able to check if anonymous users have the permission to edit a page? How
is that less ugly than a setting?
Jannis
> 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.
>
>
--
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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
> > The point is that as the developer of a reusable application you don't > know what *anyone* can do, and you should be able to abstract that by > querying the backend. > +1 As a reusable app developer, I'd prefer to develop my app and ship it with a set of permissions which control access to various aspects of functionality. It's then up to the end integrator to decide whether an anonymous user has or does not have a given permission. Allowing anonymous users to have permissions lets you put security policy in the hands of the end integrator. This has worked extremely well in the Zope/Plone world; changing a public website to one that requires authentication is simply a case of removing the standard 'View' permission from anonymous users. Cheers, Dan -- Dan Fairs | http://www.fezconsulting.com/ -- 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
@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 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 :
>
>
>
> > 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
>
> >> 2010/1/18 Alex Gaynor :
> >> > On Mon, Jan 18, 2010 at 3:55 PM, Jannis Leidel
> >> > 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 th
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
@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 :
> 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
>>
>> 2010/1/18 Alex Gaynor :
>> > On Mon, Jan 18, 2010 at 3:55 PM, Jannis Leidel
>> > 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 Goog
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
2010/1/18 Noah Silas :
> 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
>>
>> 2010/1/18 Alex Gaynor :
>> > On Mon, Jan 18, 2010 at 3:55 PM, Jannis Leidel
>> > 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.
>
>
The point is that as the developer of a reusable application you don't
know what *anyone* can do, and you should be able to abstract that by
querying the backend.
Alex
--
"I disapprove of what you say, but I will defend to the death your
right
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
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
> 2010/1/18 Alex Gaynor :
> > On Mon, Jan 18, 2010 at 3:55 PM, Jannis Leidel
> 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-developers@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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
2010/1/18 Alex Gaynor :
> On Mon, Jan 18, 2010 at 3:55 PM, Jannis Leidel 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
On Monday 18 January 2010 21:55:58 Jannis Leidel wrote: > > 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? As you say - anonymous users are by definition not *authenticated*, but that does not be that they are not *authorised*. Permissions is about authorisation, not authentication, and Harro had some good examples where you want to control authorisation for non-authenticated users in a fine-grained way. In fact, most websites assume a certain level of authorisation for non-authenticated users (ability to browse certain parts of the site etc.), so this distinction is already real, not just academic, and the patch would just make it easier to control. Luke -- "Pessimism: Every dark cloud has a silver lining, but lightning kills hundreds of people each year trying to find it." (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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
On Mon, Jan 18, 2010 at 3:55 PM, Jannis Leidel 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.
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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
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.
Some small tweaks to the patch will help:
- 'set()' is nicer than 'set([])'
- in topics/auth.html, it would be nice to document that the backend
should be able to cope with anonymous users being passed to
has_perm().
Luke
--
"Pessimism: Every dark cloud has a silver lining, but lightning
kills hundreds of people each year trying to find it." (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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
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)
And adding my own class won't work because of the same reason.
On Jan 17, 9:32 pm, Yuri Baburov wrote:
> Hi Harro,
>
> Just create a special "AnonymousUser" as User with id=0, and set it up
> with backend/middleware.
> You'll have your permissions.
>
>
>
>
>
> On Sun, Jan 17, 2010 at 2:45 PM, Harro wrote:
> > Why wouldn't a AnonymousUser have permissions?
>
> > Imagine a site where can create photo albums.
>
> > User A creates two photo albums, one to share with a specific set of
> > users and one that's public.
> > So Album A has no guest permissions, Album B has viewing permissions.
> > Now let's say you can also comment on and rate a photo. Which are two
> > separate things. For some photo's you might want to disable rating and/
> > or commenting.
> > Now you could go an add can_comment, can_rate booleans on the photo,
> > but thats not needed with row level permissions.
>
> > I really don't care how or where to store the permissions for
> > AnonymousUsers, that's up to the person implementing a backend for it,
> > I do care however about that fact that the current implementation is
> > limiting the system.
>
> > On Jan 15, 5:27 pm, Anton Bessonov wrote:
> >> No. You need row based permissions if You will limit User(!) rights. For
> >> example user can edit entries with FK 2.
> >> Seehttp://code.djangoproject.com/wiki/RowLevelPermissions
>
> >> But AnonymousUser (Guest) don't have any permissions. It's a special and
> >> that the guest can - it's not a permission - it's a setting.
>
> >> Gert Van Gool schrieb:
>
> >> > Isn't the idea of row based permission that you don't need a special
> >> > model for that?
>
> --
> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> MSN: bu...@live.com
--
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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
Hi Harro, Just create a special "AnonymousUser" as User with id=0, and set it up with backend/middleware. You'll have your permissions. On Sun, Jan 17, 2010 at 2:45 PM, Harro wrote: > Why wouldn't a AnonymousUser have permissions? > > Imagine a site where can create photo albums. > > User A creates two photo albums, one to share with a specific set of > users and one that's public. > So Album A has no guest permissions, Album B has viewing permissions. > Now let's say you can also comment on and rate a photo. Which are two > separate things. For some photo's you might want to disable rating and/ > or commenting. > Now you could go an add can_comment, can_rate booleans on the photo, > but thats not needed with row level permissions. > > I really don't care how or where to store the permissions for > AnonymousUsers, that's up to the person implementing a backend for it, > I do care however about that fact that the current implementation is > limiting the system. > > > > On Jan 15, 5:27 pm, Anton Bessonov wrote: >> No. You need row based permissions if You will limit User(!) rights. For >> example user can edit entries with FK 2. >> Seehttp://code.djangoproject.com/wiki/RowLevelPermissions >> >> But AnonymousUser (Guest) don't have any permissions. It's a special and >> that the guest can - it's not a permission - it's a setting. >> >> Gert Van Gool schrieb: >> >> >> >> > Isn't the idea of row based permission that you don't need a special >> > model for that? -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
Why wouldn't a AnonymousUser have permissions? Basically, this is senseless. For some photo's you might want to disable rating and/ or commenting. How often it is required to the user? In 99% of cases it is enough specify in an album "can" or "can not". It's really overkill of features. Now you could go an add can_comment, can_rate booleans on the photo, but thats not needed with row level permissions. The subject is "AnonymousUser has_perm/has_module_perms [...]" and it has not something in common with the row level permission support. It's are two separate things. I really don't care how or where to store the permissions for AnonymousUsers, that's up to the person implementing a backend for it, I do care however about that fact that the current implementation is limiting the system. Django's right management is basic and common. This is designed for "most apps". -- 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
Why wouldn't a AnonymousUser have permissions? Imagine a site where can create photo albums. User A creates two photo albums, one to share with a specific set of users and one that's public. So Album A has no guest permissions, Album B has viewing permissions. Now let's say you can also comment on and rate a photo. Which are two separate things. For some photo's you might want to disable rating and/ or commenting. Now you could go an add can_comment, can_rate booleans on the photo, but thats not needed with row level permissions. I really don't care how or where to store the permissions for AnonymousUsers, that's up to the person implementing a backend for it, I do care however about that fact that the current implementation is limiting the system. On Jan 15, 5:27 pm, Anton Bessonov wrote: > No. You need row based permissions if You will limit User(!) rights. For > example user can edit entries with FK 2. > Seehttp://code.djangoproject.com/wiki/RowLevelPermissions > > But AnonymousUser (Guest) don't have any permissions. It's a special and > that the guest can - it's not a permission - it's a setting. > > Gert Van Gool schrieb: > > > > > Isn't the idea of row based permission that you don't need a special > > model for that? > > > -- Gert > > > Mobile: +32 498725202 > > Web:http://gert.selentic.net -- 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
No. You need row based permissions if You will limit User(!) rights. For example user can edit entries with FK 2. See http://code.djangoproject.com/wiki/RowLevelPermissions But AnonymousUser (Guest) don't have any permissions. It's a special and that the guest can - it's not a permission - it's a setting. Gert Van Gool schrieb: Isn't the idea of row based permission that you don't need a special model for that? -- Gert Mobile: +32 498725202 Web: http://gert.selentic.net -- 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
Isn't the idea of row based permission that you don't need a special model for that? -- Gert Mobile: +32 498725202 Web: http://gert.selentic.net On Fri, Jan 15, 2010 at 13:55, Anton Bessonov wrote: > Hello, > > It's a false place. All what you need - one Model for Settings. > > if SettingsModel.objects.get(code='guest_can_comment'): > can_post > else: > cant_post > > You can wrap this in one decorator function. > > Harro schrieb: >> >> Because the authentication backend now allows for role based >> permissions you might have a blog post which anonymous users are >> allowed to comment on (create_comment) and another they can't. >> >> Now you would have to have a guest_can_comment flag or something on >> the blog post and check that before displaying the form. >> Instead I want to use the permission system to see if the anonymous >> user has create_comment permission on that specific blog item. >> >> so that's why I think this would be a good addition. >> >> It would also allow for temporary shutting down of certain publicly >> accessible items by simply removing/disabling the permissions for >> guest users. >> >> >> >> On Jan 14, 3:17 pm, Juan Pablo Scaletti >> wrote: >> >>> >>> If an AnonymousUser can do something then everybody can do that as well. >>> So why a regular unprotected view can't do the job? >>> >>> >>> >>> >>> >>> On Thu, Jan 14, 2010 at 8:13 AM, Harro wrote: >>> I was having a look at the new 1.2 row level permission support that got added and ran into the problem that the AnonymousUser does not call the authentication backend functions. The default backend doesn't need this, but with a custom backend I might want to implement Guest permissions. I think it will make the permission system even more powerful ! What do you guys think? Ticket:http://code.djangoproject.com/ticket/12557 -- 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>>> i...@googlegroups.com> . For more options, visit this group at http://groups.google.com/group/django-developers?hl=en. >>> >>> -- >>> >>> Juan Pablo Scaletti >>> > > > -- > 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
Hello, It's a false place. All what you need - one Model for Settings. if SettingsModel.objects.get(code='guest_can_comment'): can_post else: cant_post You can wrap this in one decorator function. Harro schrieb: Because the authentication backend now allows for role based permissions you might have a blog post which anonymous users are allowed to comment on (create_comment) and another they can't. Now you would have to have a guest_can_comment flag or something on the blog post and check that before displaying the form. Instead I want to use the permission system to see if the anonymous user has create_comment permission on that specific blog item. so that's why I think this would be a good addition. It would also allow for temporary shutting down of certain publicly accessible items by simply removing/disabling the permissions for guest users. On Jan 14, 3:17 pm, Juan Pablo Scaletti wrote: If an AnonymousUser can do something then everybody can do that as well. So why a regular unprotected view can't do the job? On Thu, Jan 14, 2010 at 8:13 AM, Harro wrote: I was having a look at the new 1.2 row level permission support that got added and ran into the problem that the AnonymousUser does not call the authentication backend functions. The default backend doesn't need this, but with a custom backend I might want to implement Guest permissions. I think it will make the permission system even more powerful ! What do you guys think? Ticket:http://code.djangoproject.com/ticket/12557 -- 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. -- Juan Pablo Scaletti -- 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
Because the authentication backend now allows for role based permissions you might have a blog post which anonymous users are allowed to comment on (create_comment) and another they can't. Now you would have to have a guest_can_comment flag or something on the blog post and check that before displaying the form. Instead I want to use the permission system to see if the anonymous user has create_comment permission on that specific blog item. so that's why I think this would be a good addition. It would also allow for temporary shutting down of certain publicly accessible items by simply removing/disabling the permissions for guest users. On Jan 14, 3:17 pm, Juan Pablo Scaletti wrote: > If an AnonymousUser can do something then everybody can do that as well. > So why a regular unprotected view can't do the job? > > > > > > On Thu, Jan 14, 2010 at 8:13 AM, Harro wrote: > > I was having a look at the new 1.2 row level permission support that > > got added and ran into the problem that the AnonymousUser does not > > call the authentication backend functions. > > > The default backend doesn't need this, but with a custom backend I > > might want to implement Guest permissions. > > > I think it will make the permission system even more powerful ! > > > What do you guys think? > > > Ticket:http://code.djangoproject.com/ticket/12557 > > > -- > > 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 > i...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/django-developers?hl=en. > > -- > > Juan Pablo Scaletti -- 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.
Re: AnonymousUser has_perm/has_module_perms function check authentication backends
If an AnonymousUser can do something then everybody can do that as well. So why a regular unprotected view can't do the job? On Thu, Jan 14, 2010 at 8:13 AM, Harro wrote: > I was having a look at the new 1.2 row level permission support that > got added and ran into the problem that the AnonymousUser does not > call the authentication backend functions. > > The default backend doesn't need this, but with a custom backend I > might want to implement Guest permissions. > > I think it will make the permission system even more powerful ! > > What do you guys think? > > > Ticket: http://code.djangoproject.com/ticket/12557 > > -- > 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. > > > > -- Juan Pablo Scaletti -- 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.
AnonymousUser has_perm/has_module_perms function check authentication backends
I was having a look at the new 1.2 row level permission support that got added and ran into the problem that the AnonymousUser does not call the authentication backend functions. The default backend doesn't need this, but with a custom backend I might want to implement Guest permissions. I think it will make the permission system even more powerful ! What do you guys think? Ticket: http://code.djangoproject.com/ticket/12557 -- 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.
