Jorge Vargas schrieb:
> On Fri, Oct 16, 2009 at 11:28 AM, Diez B. Roggisch <[email protected]> wrote:
>> Chris Seberino schrieb:
>>>
>>> On Oct 16, 3:05 am, Christopher Arndt <[email protected]> wrote:
>>>
>>>> Can you give a more complete code example of what you are trying to do?
>>>> I believe that these functions are not decorators but *generate* 
>>>> decorators.
>>> I've been using my own custom lightweight auth system for years...
>>> I was just curious what the last line does.
>>> I thought any function that returned a function was *already* a
>>> decorator!?
>>>
>>> def access_control(function):
>>>         """
>>>         Decorator that denies access without authentication.
>>>         """
>>>
>>>         def new_function(function, *parameters, **keywords):
>>>                 """
>>>                 Adds a wrapper requiring authentication.
>>>                 """
>>>
>>>                 if ("logged_in" in cherrypy.session)
>>> and                      \
>>>                    cherrypy.session["logged_in"]:
>>>                         return function(*parameters, **keywords)
>>>                 else:
>>>                         raise turbogears.redirect("/access_control_/
>>> log_in")
>>>
>>>         return new_function
>>> access_control = turbogears.decorator.decorator(access_control)
>> The problem with this is the same as with the IMHO much to over-generic
>> repoze.w*-system that is TG2-agnostic: you will get you decorator
>> executed *after* validation has taken place.
>>
>> Now depending on your site, this might impose a security-risk, if
>> validator-code is thus run for users that don't have the necessary
>> privileges.
> 
> This is not entirely accurate. In both tg1 and tg2 the decorators are
> more like "registries" so when you load the controller they get
> processed and stored in the decoration. On each call from the web the
> decoration is ran which effectively means it gets called on every run.

No. The question of Chris S. was "why use tg.decorators". And the answer 
is "because then they will be registered in the Decoration", whereas the 
normal way of decorating he uses & which is used in repoze.what bypasses 
that registry, and instead wraps the action itself.

So it becomes dependant on decoration order, and there are hooks in the 
Decoration such as before_validate, before_call that will *always* run 
before those "standard" decorators. Which might impose risks, or 
otherwise undesired behavior.

Diez

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to