AnonymousUser has_perm/has_module_perms function check authentication backends
Harro
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?
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-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
--
Juan Pablo Scaletti
Harro
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 <juanpablo.scale...@gmail.com>
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 <hvdkl...@gmail.com> 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-d...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-develop...@googlegroups.com<django-developers%2Bunsubscr i...@googlegroups.com>
Anton Bessonov
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:
Gert Van Gool
model for that?
-- Gert
Mobile: +32 498725202
Web: http://gert.selentic.net
> django-develop...@googlegroups.com.
Anton Bessonov
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:
Harro
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 <exe...@googlemail.com> 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
Anton Bessonov
> Why wouldn't a AnonymousUser have permissions?
>
> For some photo's you might want to disable rating and/
> or commenting.
>
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.
>
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.
"most apps".
Yuri Baburov
Just create a special "AnonymousUser" as User with id=0, and set it up
with backend/middleware.
You'll have your permissions.
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
Harro
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.
Luke Plant
> 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/
Jannis Leidel
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
Alex Gaynor
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@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
Luke Plant
> > 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.
Łukasz Rekucki
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-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>
>
>
--
Łukasz Rekucki
Noah Silas
~Noah Silas
Alex Gaynor
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.
Gert Van Gool
some objects (while it's possible on others).
-- Gert
Mobile: +32 498725202
Web: http://gert.selentic.net
2010/1/19 Noah Silas <no...@mahalo.com>:
Harro
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>:
Dan Fairs
> 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 <dan....@gmail.com> | http://www.fezconsulting.com/
Jannis Leidel
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
Jannis Leidel
> 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
Luke Plant
> > 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/
Jannis Leidel
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
Harro
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.
Harro
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 <jan...@leidel.info> wrote:
Luke Plant
> 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
Harro
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)
Harro
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.
Jari Pennanen
of Django, any status on that? Is someone trying to commit the patches?
Harro
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.
Luke Plant
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/
Florian Apolloner
> - 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.
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)
Harro
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 :)
Harro
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
Florian Apolloner
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
Florian Apolloner
> 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 :)
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)