[Zope-dev] 2.7 branch: attribute permission problems
chrism at plope.com
Tue Sep 14 23:00:40 EDT 2004
On Tue, 2004-09-14 at 22:49, Richard Jones wrote:
> > Yup. IOW, it looks like it used to find the first "secure_url" it could
> > access and return that, even if there were other acquirable "secure_url"
> > attrs before that one in the acquisition path. I'm sure the fact that
> > it ignores any intermediate (but inaccessible) "secure_url" attrs is
> > what Tres meant by DWIM.
> I *think* you're implying that there might be more than one secure_url
> attribute in the acquisition path? If so, that's not the case. There is only
> one, and it's on B.
> Or perhaps what you're saying is that in the pre-patch days, if there *was* an
> attribute on A, then validate() would do the Wrong Thing, or something
> otherwise bad would happen.
In the pre-patch days, guarded getattr did "validate" on basically every
object in the acquisition chain and returned the first attribute that
the user could access in that chain.
Now guarded_getattr relies on whatever "validate" does when it receives
the top-level object and doesn't try to do anything fancy to find an
I'd just stick the code back in there for now and we'll see what Tres
> I'm a little confused about why I'm the only person seeing this, BTW...
Me too. It'd be nice if "A" had a secure_url attribute, then it might
even be explicable. I don't have the patience at the moment to pdb
through validate, so I can only guess why it is actually happening. ;-)
> > But I'm not sure that he intended for the patch to have this effect.
> > I'm not even sure why it does have this effect; the "validate" function
> > is just too byzantine to understand without taking it through the
> > debugger.
> You can say that again. My head hurts every time I need to look into
> validate() and friends ;)
It could be worse, you could have found a problem in
More information about the Zope-Dev