The default "acl search" algorithm is to stop at the first entry (ace) that
matches both the permission and a principal. So yeah, the Deny should be
before the Allow in your example.
On Wed, Mar 14, 2012 at 2:25 AM, Mark <zhengha...@gmail.com> wrote:
> Hi Michael,
>
> Can I describe another likely situation?
>
> What if USER Timothy has the role of 'EDITOR' with read and update
> permissions on a specific resource, BUT....because of some condition, eg.
> if his sales is lesser than 100/month (let's call this attribute
> sales_per_month), he can only read and NOT update that resource. How would
> this acl be?
>
> @property
> def __acl__(self):
> return [
> (Allow, 'editor', ('read', 'update'),
> (Deny, 'sales_lesser_than_100', 'update')
> ]
>
> Should the deny be first in the list or should it be at the end?
>
>
> On Wednesday, 14 March 2012 00:06:05 UTC-5, Michael Merickel wrote:
>>
>> On Tue, Mar 13, 2012 at 11:52 PM, Mark <zhengha...@gmail.com> wrote:
>>
>>> 1. Does the above scenario mean that EVERY time a brand is created in
>>> the system, I would have to generate for instance, "b1_create",
>>> "b1_read" .... "b1_delete", "b2_create", "b2_read", "b2_update" ...
>>> "b4_delete" permissions?
>>>
>>
>> The way I would approach the problem is to have a "create", "read" and
>> "delete" permissions. When accessing a context of type B, it would then
>> supply an __acl__ which is dynamically generated based on its origins. For
>> example:
>>
>> @property
>> def __acl__(self):
>> return [
>> (Allow, 'editor', ('read', 'update')),
>> (Allow, 'origin:' + self.origin, 'delete'),
>> ]
>>
>> With this, the object of type B has told us "who" is allowed to delete
>> it. Now when Timothy accesses the system, it would be the responsibility of
>> the authentication policy via the groupfinder to return a list of
>> principals for Timothy. For example, Timothy is from france, so you would
>> add the 'origin:france' principal, and he is an editor so you would add the
>> 'editor' principal. Now when the auth system compares B's acl to timothy's
>> principals, he will only have the delete permission if one of his
>> principals matches up with one of the ACE's providing delete.
>>
>>
>>> Another example would be something like:
>>>
>>> An agent of a company can make orders. However, he should only be
>>> able to select the products (this means read permission right?) from
>>> his country. If he is an agent of France, he can only make orders of
>>> products that are only for France, not those in Germany or Holland.
>>> How would the ACL for this work....?
>>>
>>
>> Again, look at it from the perspective of the context (the object of
>> interest). That object (the product) should provide an ACL that tells the
>> auth system what principals are allowed to use it. For example the product
>> returns (Allow, 'agent_of_'+self.origin, 'read') where self is a product.
>> The auth system then compares these acls with the principals returned by
>> the authentication policy.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/pylons-discuss/-/mbA2i1_cOdMJ.
>
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-discuss+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-discuss?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
