__bobo_traverse__ and a no-object
Hi all! Please, look at this code: def __bobo_traverse__(self, REQUEST, name): obj = getattr(self, name, None) if obj is not None: return obj else: obj = self.Dame(name) if obj is not None: return obj else: if 'Parametros' in self.REQUEST: self.REQUEST['Parametros'] = self.REQUEST['Parametros'] + [name] else: self.REQUEST['Parametros'] = [name] return self self.Dame is a function that seeks for an object with the name "name" I wonder why I can do this on a Page Template: <tal:b tal:replace='python: here.Texto' /> Where Texto is a adquired property, but not this: <tal:b tal:replace='here/Texto' /> because zope raises an unauthorized error How can I solve this point? Thanks! -- Mis Cosas http://blogs.sistes.net/Garito
Garito escribió:
Hi all!
Please, look at this code:
def __bobo_traverse__(self, REQUEST, name): obj = getattr(self, name, None) if obj is not None: return obj else: obj = self.Dame(name) if obj is not None: return obj else: if 'Parametros' in self.REQUEST: self.REQUEST['Parametros'] = self.REQUEST['Parametros'] + [name] else: self.REQUEST['Parametros'] = [name] return self
self.Dame is a function that seeks for an object with the name "name"
I wonder why I can do this on a Page Template:
<tal:b tal:replace='python: here.Texto' />
Where Texto is a adquired property, but not this:
<tal:b tal:replace='here/Texto' />
because zope raises an unauthorized error
How can I solve this point?
Thanks!
Anyone can tell me what is happening here? -- Mis Cosas http://blogs.sistes.net/Garito
Andreas Jung escribió:
--On 14. Juli 2006 17:17:51 +0200 Garito <garito@sistes.net> wrote:
Garito escribió:
Anyone can tell me what is happening here?
The Zope mailing list is not a helpdesk with a guaranteed response time. No need to grouch!
-aj
Sorry I don't pretend to be rude! -- Mis Cosas http://blogs.sistes.net/Garito
Garito wrote at 2006-7-14 07:04 +0200:
... def __bobo_traverse__(self, REQUEST, name): obj = getattr(self, name, None) ... I wonder why I can do this on a Page Template:
<tal:b tal:replace='python: here.Texto' />
Where Texto is a adquired property, but not this:
<tal:b tal:replace='here/Texto' />
because zope raises an unauthorized error
How can I solve this point?
You can wait for the next Zope release (2.10) where this is fixed. The reason: security for "__bobo_traverse__" is much stricter than for attribute lookup: In the latter case, the security machinery knows that the value was obtained by attribute lookup and can apply the security declarations of the accessed object. In the former case, the security machinery does not know which object was really accessed and therefore refuses to look at the accessed object. This often leads to an "Unauthorized". The hack in Zope 2.10 checks in this case whether the value could as well have been obtained by attribute lookup and then checks along this route. If waiting is not an option for you, you can also backport the fix to your Zope version. -- Dieter
On 7/14/06, Dieter Maurer <dieter@handshake.de> wrote:
Garito wrote at 2006-7-14 07:04 +0200:
... def __bobo_traverse__(self, REQUEST, name): obj = getattr(self, name, None) ... I wonder why I can do this on a Page Template:
<tal:b tal:replace='python: here.Texto' />
Where Texto is a adquired property, but not this:
<tal:b tal:replace='here/Texto' />
because zope raises an unauthorized error
How can I solve this point?
You can wait for the next Zope release (2.10) where this is fixed.
The reason: security for "__bobo_traverse__" is much stricter than for attribute lookup:
In the latter case, the security machinery knows that the value was obtained by attribute lookup and can apply the security declarations of the accessed object.
In the former case, the security machinery does not know which object was really accessed and therefore refuses to look at the accessed object. This often leads to an "Unauthorized".
The hack in Zope 2.10 checks in this case whether the value could as well have been obtained by attribute lookup and then checks along this route.
If waiting is not an option for you, you can also backport the fix to your Zope version.
Hm, if this is the issue, the fix should already be in Zope 2.9.3 and 2.8.7 Alec
Dieter Maurer escribió:
Garito wrote at 2006-7-14 07:04 +0200:
... def __bobo_traverse__(self, REQUEST, name): obj = getattr(self, name, None) ... I wonder why I can do this on a Page Template:
<tal:b tal:replace='python: here.Texto' />
Where Texto is a adquired property, but not this:
<tal:b tal:replace='here/Texto' />
because zope raises an unauthorized error
How can I solve this point?
You can wait for the next Zope release (2.10) where this is fixed.
The reason: security for "__bobo_traverse__" is much stricter than for attribute lookup:
In the latter case, the security machinery knows that the value was obtained by attribute lookup and can apply the security declarations of the accessed object.
In the former case, the security machinery does not know which object was really accessed and therefore refuses to look at the accessed object. This often leads to an "Unauthorized".
The hack in Zope 2.10 checks in this case whether the value could as well have been obtained by attribute lookup and then checks along this route.
If waiting is not an option for you, you can also backport the fix to your Zope version.
Hi Dieter! In fact all my work depends on this question (this is the reason behind my nervous. Sorry again Andreas and the rest of people) Do you know how can I find information to backport the fix? -- Mis Cosas http://blogs.sistes.net/Garito
Dieter Maurer escribió:
Garito wrote at 2006-7-14 07:04 +0200:
... def __bobo_traverse__(self, REQUEST, name): obj = getattr(self, name, None) ... I wonder why I can do this on a Page Template:
<tal:b tal:replace='python: here.Texto' />
Where Texto is a adquired property, but not this:
<tal:b tal:replace='here/Texto' />
because zope raises an unauthorized error
How can I solve this point?
You can wait for the next Zope release (2.10) where this is fixed.
The reason: security for "__bobo_traverse__" is much stricter than for attribute lookup:
In the latter case, the security machinery knows that the value was obtained by attribute lookup and can apply the security declarations of the accessed object.
In the former case, the security machinery does not know which object was really accessed and therefore refuses to look at the accessed object. This often leads to an "Unauthorized".
The hack in Zope 2.10 checks in this case whether the value could as well have been obtained by attribute lookup and then checks along this route.
If waiting is not an option for you, you can also backport the fix to your Zope version.
Do you refer this Collector? http://www.zope.org/Collectors/Zope/2072 -- Mis Cosas http://blogs.sistes.net/Garito
Garito escribió:
Dieter Maurer escribió:
Garito wrote at 2006-7-14 07:04 +0200:
... def __bobo_traverse__(self, REQUEST, name): obj = getattr(self, name, None) ... I wonder why I can do this on a Page Template:
<tal:b tal:replace='python: here.Texto' />
Where Texto is a adquired property, but not this:
<tal:b tal:replace='here/Texto' />
because zope raises an unauthorized error
How can I solve this point?
You can wait for the next Zope release (2.10) where this is fixed.
The reason: security for "__bobo_traverse__" is much stricter than for attribute lookup:
In the latter case, the security machinery knows that the value was obtained by attribute lookup and can apply the security declarations of the accessed object.
In the former case, the security machinery does not know which object was really accessed and therefore refuses to look at the accessed object. This often leads to an "Unauthorized".
The hack in Zope 2.10 checks in this case whether the value could as well have been obtained by attribute lookup and then checks along this route.
If waiting is not an option for you, you can also backport the fix to your Zope version.
Do you refer this Collector?
I use Zope 2.9.2 -- Mis Cosas http://blogs.sistes.net/Garito
On 7/14/06, Garito <garito@sistes.net> wrote:
Garito escribió:
Dieter Maurer escribió:
Garito wrote at 2006-7-14 07:04 +0200:
... def __bobo_traverse__(self, REQUEST, name): obj = getattr(self, name, None) ... I wonder why I can do this on a Page Template:
<tal:b tal:replace='python: here.Texto' />
Where Texto is a adquired property, but not this:
<tal:b tal:replace='here/Texto' />
because zope raises an unauthorized error
How can I solve this point?
You can wait for the next Zope release (2.10) where this is fixed.
The reason: security for "__bobo_traverse__" is much stricter than for attribute lookup:
In the latter case, the security machinery knows that the value was obtained by attribute lookup and can apply the security declarations of the accessed object.
In the former case, the security machinery does not know which object was really accessed and therefore refuses to look at the accessed object. This often leads to an "Unauthorized".
The hack in Zope 2.10 checks in this case whether the value could as well have been obtained by attribute lookup and then checks along this route.
If waiting is not an option for you, you can also backport the fix to your Zope version.
Do you refer this Collector?
I use Zope 2.9.2
Use 2.9.3 and watch your problem disappear (hopefully). Alec
Alec Mitchell escribió:
On 7/14/06, Garito <garito@sistes.net> wrote:
Garito escribió:
Dieter Maurer escribió:
Garito wrote at 2006-7-14 07:04 +0200:
... def __bobo_traverse__(self, REQUEST, name): obj = getattr(self, name, None) ... I wonder why I can do this on a Page Template:
<tal:b tal:replace='python: here.Texto' />
Where Texto is a adquired property, but not this:
<tal:b tal:replace='here/Texto' />
because zope raises an unauthorized error
How can I solve this point?
You can wait for the next Zope release (2.10) where this is fixed.
The reason: security for "__bobo_traverse__" is much stricter than for attribute lookup:
In the latter case, the security machinery knows that the value was obtained by attribute lookup and can apply the security declarations of the accessed object.
In the former case, the security machinery does not know which object was really accessed and therefore refuses to look at the accessed object. This often leads to an "Unauthorized".
The hack in Zope 2.10 checks in this case whether the value could as well have been obtained by attribute lookup and then checks along this route.
If waiting is not an option for you, you can also backport the fix to your Zope version.
Do you refer this Collector?
I use Zope 2.9.2
Use 2.9.3 and watch your problem disappear (hopefully).
Alec Completely disappeared!!!
Thank you so much!!!!!! -- Mis Cosas http://blogs.sistes.net/Garito
participants (4)
-
Alec Mitchell -
Andreas Jung -
Dieter Maurer -
Garito