Anthony,
Thanks so much for sharing the expertise, and so quickly.
I had completely misunderstood about the decorators. Actually stacking them
is the simplest and easiest answer, given that it is a valid thing to do.
I hear what you say about the unnecessary database hits and the lambda. I
had read the other string about this: "Authorization decorators always
generate db queries" that you had kindly posted to. This was something else
I misunderstood as I thought an update was applied to this on 11/18/11.
Oops sorry, I will be sure to take your advice on this point also.
So, answer is: stacking the decorators and adding lambda to
@auth.requires(auth.has_membership.....
Thanks again
Simon
On Friday, April 12, 2013 2:34:06 PM UTC+1, Anthony wrote:
>
> @auth.requires(auth.has_membership('Approver') or
>> auth.has_membership('Admin')) #allowing Admin or Approvers to access
>
>
> The above will execute the has_membership queries every time the
> controller is called, even when not accessing the decorated function. To
> avoid the unnecessary database hits, you can put the condition inside a
> lambda (so it will only get called when the decorated function is actually
> accessed):
>
> @auth.requires(lambda: auth.has_membership('Approver') or auth.
> has_membership('Admin'))
>
> 1) How do I combine these decorators to include BOTH group membership and
>> requires_signature() ?
>> 2) Can I use multiple,separate decorators for a function()? (I am sure
>> not)
>>
>
> Yes, decorators can be stacked:
>
> @auth.requires_signature()
> @auth.requires(some_condition)
> def myfunc():
> ...
>
>
>> 3) It is also possible to add addtional conditions to @auth.requires()
>> e.g. mytable.department==auth.user.department (for added security!)
>>
>
> Yes, the first argument to @auth.requires() can be any expression -- its
> truthiness will be evaluated to determine whether access is granted. It can
> also be a callable, it which case, it will be called and the return value
> will be evaluated (hence the recommendation above to put the membership
> checks inside a lambda).
>
>
>> 4) Or maybe there is there is a better way to prevent manual fiddling
>> with the URL/ARG ?
>>
>
> Digitally signing the URLs is a good method for this. The signature is
> actually a hash of the URL itself (minus the signature, of course). When
> the request is made, web2py re-hashes the requested URL and makes sure it
> matches the signature -- if not, that means the URL was modified, and
> access is denied.
>
> The other option would be to check for permission on the requested record,
> but the signature is probably the best approach, as it doesn't require
> another database query to check permission.
>
> Anthony
>
--
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
