Re: [Zope] __bobo_traverse__ help
Dieter Maurer escribió: Garito wrote at 2006-11-10 15:00 +0100: ... You may try to return a wrapper that behaves the same way as the original object (by deriving from the respective type) but has "__roles__ = None" as additional attribute (which declares the object public). Uau! Can you point me to a simple example or similar? I'm not sure if I understand what you are telling me Here is a wrapper for the "str" type: class WrappedStr(str): __roles__ = None Instead of returning "some_str" you would return "WrappedStr(some_str)". The "__roles__ = None" tells the Zope security machinery that the object is public. "WrappedStr(some_str)" would almost behave like "some_str" (but of course not completely). Hi! Perfect, that's what I need (I hope so :-) ) Thank you so much, I try it! -- Mis Cosas http://blogs.sistes.net/Garito ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] __bobo_traverse__ help
Garito wrote at 2006-11-10 15:00 +0100: > ... >> You may try to return a wrapper that behaves the same way >> as the original object (by deriving from the respective type) >> but has "__roles__ = None" as additional attribute (which declares >> the object public). >> >> >> >> >Uau! >Can you point me to a simple example or similar? I'm not sure if I >understand what you are telling me Here is a wrapper for the "str" type: class WrappedStr(str): __roles__ = None Instead of returning "some_str" you would return "WrappedStr(some_str)". The "__roles__ = None" tells the Zope security machinery that the object is public. "WrappedStr(some_str)" would almost behave like "some_str" (but of course not completely). -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] __bobo_traverse__ help
Dieter Maurer escribió: Garito wrote at 2006-11-9 03:07 +0100: ... What you see is an authentication weekness with "__bobo_traverse__": Zope's security machinery requires acquisition wrappers to work reliably. When "__bobo_traverse__" returns a non acquisition wrapped object without public security declarations, then the normal security check would not help. Zope therefore tries to check whether a standard 'getattr' would return the same object and accept it in this case. Otherwise, it will raise "Unauthorized" with the intent that an unmotivated "Unauthorized" is better than giving access to some piece of information that should be protected. In my view, the behaviour is buggy as "__bobo_traverse__" has no way to return a non-trivial elementary data type -- but almost surely, it will not be changed... ... Then: what solution did you think will be the best solution for my request? You may try to return a wrapper that behaves the same way as the original object (by deriving from the respective type) but has "__roles__ = None" as additional attribute (which declares the object public). Uau! Can you point me to a simple example or similar? I'm not sure if I understand what you are telling me Thanks! -- Mis Cosas http://blogs.sistes.net/Garito ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] __bobo_traverse__ help
Garito wrote at 2006-11-9 03:07 +0100: > ... >> What you see is an authentication weekness with "__bobo_traverse__": >> >> Zope's security machinery requires acquisition wrappers >> to work reliably. >> >> When "__bobo_traverse__" returns a non acquisition wrapped >> object without public security declarations, then the >> normal security check would not help. >> >> Zope therefore tries to check whether a standard 'getattr' would >> return the same object and accept it in this case. >> Otherwise, it will raise "Unauthorized" with the intent >> that an unmotivated "Unauthorized" is better than giving >> access to some piece of information that should be protected. >> >> >> In my view, the behaviour is buggy as "__bobo_traverse__" has >> no way to return a non-trivial elementary data type -- but >> almost surely, it will not be changed... > ... >Then: what solution did you think will be the best solution for my request? You may try to return a wrapper that behaves the same way as the original object (by deriving from the respective type) but has "__roles__ = None" as additional attribute (which declares the object public). -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] __bobo_traverse__ help
Dieter Maurer escribió:
Garito wrote at 2006-11-8 02:50 +0100:
Please consider this code:
def __bobo_traverse__(self, REQUEST, name):
obj = self.Propiedad(name)
if obj is None: return self
else: return obj
def Propiedad(self, propiedad):
obj = getattr(self, propiedad, None)
if obj is None: return obj # Añadir busqueda al catalogo
else:
if type(obj) == type(str('')) and obj.startswith('[') and
obj.endswith(']'):
return self.Expresion({'Expresion': obj[1:-1]})['Resultado']
return obj
I wonder why I can do:
but not:
...
When I try here/Modificacion an unauthorized error trying to access
Modificacion
What you see is an authentication weekness with "__bobo_traverse__":
Zope's security machinery requires acquisition wrappers
to work reliably.
When "__bobo_traverse__" returns a non acquisition wrapped
object without public security declarations, then the
normal security check would not help.
Zope therefore tries to check whether a standard 'getattr' would
return the same object and accept it in this case.
Otherwise, it will raise "Unauthorized" with the intent
that an unmotivated "Unauthorized" is better than giving
access to some piece of information that should be protected.
In my view, the behaviour is buggy as "__bobo_traverse__" has
no way to return a non-trivial elementary data type -- but
almost surely, it will not be changed...
Hi Dieter!
Then: what solution did you think will be the best solution for my request?
Thanks!
--
Mis Cosas
http://blogs.sistes.net/Garito
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] __bobo_traverse__ help
Garito wrote at 2006-11-8 02:50 +0100:
>Please consider this code:
>
>def __bobo_traverse__(self, REQUEST, name):
>obj = self.Propiedad(name)
>if obj is None: return self
>else: return obj
>
>def Propiedad(self, propiedad):
>obj = getattr(self, propiedad, None)
>if obj is None: return obj # Añadir busqueda al catalogo
>else:
>if type(obj) == type(str('')) and obj.startswith('[') and
>obj.endswith(']'):
>return self.Expresion({'Expresion': obj[1:-1]})['Resultado']
>return obj
>
>I wonder why I can do:
>
>
>
>but not:
>
>
> ...
>When I try here/Modificacion an unauthorized error trying to access
>Modificacion
What you see is an authentication weekness with "__bobo_traverse__":
Zope's security machinery requires acquisition wrappers
to work reliably.
When "__bobo_traverse__" returns a non acquisition wrapped
object without public security declarations, then the
normal security check would not help.
Zope therefore tries to check whether a standard 'getattr' would
return the same object and accept it in this case.
Otherwise, it will raise "Unauthorized" with the intent
that an unmotivated "Unauthorized" is better than giving
access to some piece of information that should be protected.
In my view, the behaviour is buggy as "__bobo_traverse__" has
no way to return a non-trivial elementary data type -- but
almost surely, it will not be changed...
--
Dieter
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
