@auth.requires_membership() was changed so it only does its query when the
decorated function is actually called. However, you are using the more
generic @auth.requires(), which can take any condition. There's no way to
automatically make the evaluation of that condition lazy, so you are
responsible for putting it inside a callable (e.g., a lambda) yourself.
On Friday, April 12, 2013 10:08:35 AM UTC-4, SimonD wrote:
>
> 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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
