Re: [Zope] Some __bobo_traverse__ help
Garito wrote at 2007-3-27 02:50 +0200: How could be the __bobo_traverse__ to work as expected with out losting traverse_subpath? You need to do strange things in __bobo_traverse__ to loose the traverse_subpath: in fact, you need to tamper with the TraversalRequestNameStack, or to no longer traverse to the objects that set the traverse_subpath (in their __before_publishing_traverse__ hook). I fear you need to go back to the drawing board. When I remember right, then your primary problem has been that Zope's security machinery fails when __bobo_traverse__ returns objects which are neither acquisition wrapped nor have their own security declarations (such as strings, unicode, etc). Therefore, I suggested that you instead of the elementary types return wrappers for those types which behave identical to them but in addition have the security declaration __roles__ = None (which means the object is public). That seemed to work quite well for some time. Now you are facing obscure problems (a user is not authenticated although you think it should be). Unless you are URL traversing to one of the wrappers above (which you should not do of course), this problem should have nothing to do with the wrappers. Almost surely, it is a different problem -- which one, I cannot tell you. But, I gave some hints as to how I would proceed to understand the problem. -- 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] Some __bobo_traverse__ help
Forget it Dieter! Finally what I do is do the normal traverse (with the bobo_traverse) and I use another REQUEST variable (pathTraverse) to store the list expected at traverse_subpath and return the last object founded I pretty sure (I don't test it for now) I can reconstruct TraversalRequestNameStack at __call__ level Now I don't need the wrappers but the code goes fine I didn't like so much the pathTraverse solution but works for me and that's the real important think Thanks and sorry! 2007/3/27, Dieter Maurer [EMAIL PROTECTED]: Garito wrote at 2007-3-27 02:50 +0200: How could be the __bobo_traverse__ to work as expected with out losting traverse_subpath? You need to do strange things in __bobo_traverse__ to loose the traverse_subpath: in fact, you need to tamper with the TraversalRequestNameStack, or to no longer traverse to the objects that set the traverse_subpath (in their __before_publishing_traverse__ hook). I fear you need to go back to the drawing board. When I remember right, then your primary problem has been that Zope's security machinery fails when __bobo_traverse__ returns objects which are neither acquisition wrapped nor have their own security declarations (such as strings, unicode, etc). Therefore, I suggested that you instead of the elementary types return wrappers for those types which behave identical to them but in addition have the security declaration __roles__ = None (which means the object is public). That seemed to work quite well for some time. Now you are facing obscure problems (a user is not authenticated although you think it should be). Unless you are URL traversing to one of the wrappers above (which you should not do of course), this problem should have nothing to do with the wrappers. Almost surely, it is a different problem -- which one, I cannot tell you. But, I gave some hints as to how I would proceed to understand the problem. -- Dieter -- 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] Some __bobo_traverse__ help
On 3/26/07, Dieter Maurer [EMAIL PROTECTED] wrote: Martijn is a Five expert and told you things that may happen when Five is heavily used. Not as much as the other one though. ;) I (Martijn Pieters) attempted to help out, Martijn Faassen is the Five expert. I do not think that your problem is Five related -- and I am almost convinced that it is not related to your wrappers. This is not a Five problem. Unfortunately, I cannot tell you what causes your problem. It seems to be authentication related. I would verify REQUEST._auth (you told us, you were using HTTP basic authentication; then REQUEST._auth should contain the authorization info from the request) in your debugging session. One potentially important hint from Martijn is to check where the failing validate is called. If the call comes from traversal, then authentication did not yet happen (as Martijn has pointed out). I suspect that he is doing something at traversal time that requires a logged-in user. The publisher, however, won't look for a user until after traversal: 1) Traverse the URL 2) Look up user in the returned context 3) Call whatever traversal returned If his __bobo_traverse__ returned a callable that does the dirty work, the problem should be resolved. Compare this to Five views, for example. They are objects with a __call__ method. They are constructed at traversal time (__init__ is called), and then called (__call__ is executed). -- Martijn Pieters ___ 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] Some __bobo_traverse__ help
Hi Martijn and Dieter! Martijn is correct, absolutely! At my product __bobo_traverse__ is calling __call__ method who do the dirty work How could be the __bobo_traverse__ to work as expected with out losting traverse_subpath? I can't return self without losting traverse_subpath list and that's because I don't return self to execute __call__ (index_html returns __call__ too) Thanks!!! 2007/3/26, Martijn Pieters [EMAIL PROTECTED]: On 3/26/07, Dieter Maurer [EMAIL PROTECTED] wrote: Martijn is a Five expert and told you things that may happen when Five is heavily used. Not as much as the other one though. ;) I (Martijn Pieters) attempted to help out, Martijn Faassen is the Five expert. I do not think that your problem is Five related -- and I am almost convinced that it is not related to your wrappers. This is not a Five problem. Unfortunately, I cannot tell you what causes your problem. It seems to be authentication related. I would verify REQUEST._auth (you told us, you were using HTTP basic authentication; then REQUEST._auth should contain the authorization info from the request) in your debugging session. One potentially important hint from Martijn is to check where the failing validate is called. If the call comes from traversal, then authentication did not yet happen (as Martijn has pointed out). I suspect that he is doing something at traversal time that requires a logged-in user. The publisher, however, won't look for a user until after traversal: 1) Traverse the URL 2) Look up user in the returned context 3) Call whatever traversal returned If his __bobo_traverse__ returned a callable that does the dirty work, the problem should be resolved. Compare this to Five views, for example. They are objects with a __call__ method. They are constructed at traversal time (__init__ is called), and then called (__call__ is executed). -- Martijn Pieters -- 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 )
[Zope] Some __bobo_traverse__ help
Hi!
Some one could help me to construct a correct __bobo_traverse__ or wrapper
for my necesities.
The clues:
I have this model of __bobo_traverse__:
def __bobo_traverse__(self, REQUEST, nombre):
obj = getattr(self, nombre, None)
if obj is None:
self.REQUEST.set('TraversalRequestNameStack',
self.REQUEST[TraversalRequestNameStack]
+ [nombre])
if hasattr(self, 'index.html'): return getattr(self, 'index.html
')
else:
resultado = self.__call__()
if type(resultado) == type(unicode()): return
WrapperUnicode(resultado)
elif type(resultado) == type(str()): return
WrapperStr(resultado)
elif type(resultado) == type(dict()): return
WrapperDict(resultado)
else: return resultado
return obj
With this Wrapper classes:
class WrapperStr(str):
__roles__ = None
def __bobo_traverse__(self, REQUEST, nombre):
obj = getattr(self, nombre, None)
if obj is None: return self
else: return obj
class WrapperUnicode(unicode):
__roles__ = None
def __init__(self, cadena):
self.cadena = cadena
def __bobo_traverse__(self, REQUEST, nombre):
obj = getattr(self, nombre, None)
if obj is None: return self
else: return obj.__of__(self)
def __call__(self):
return self.cadena
def __str__(self):
return str(self.cadena.decode('latin-1'))
class WrapperDict(dict):
__roles__ = None
def __bobo_traverse__(self, REQUEST, nombre):
obj = getattr(self, nombre, None)
if obj is None: return self
else: return obj
With this version I have the security problem I'm asking this days. The last
opinion was the Wrapper classes are the problem but you could see the
wrappers I can do with the information I have
But if I change the __bobo_traverse__ to this:
def __bobo_traverse__(self, REQUEST, nombre):
obj = getattr(self, nombre, None)
if obj is None:
self.REQUEST.set('TraversalRequestNameStack',
self.REQUEST[TraversalRequestNameStack]
+ [nombre])
if hasattr(self, 'index.html'): return getattr(self, 'index.html
')
else:
obj = getattr(self, 'lanzador', None)
return obj
Where lanzador is a page template with this code:
tal:b tal:replace='structure here' /
Then it works perfect!! (we can conclude, then, that Martijn has good clues
about the problem, thanks again!)
Here my petition of help:
Could someone explain or point me to how the wrappers need to be? I don't
like so much the idea that all my work depends on a page template with 1
line of code if I could implement it at product code
Thank you!
--
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 )
