[Zope-dev] 2.7 branch: attribute permission problems

[Chris McDonough]

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.

Yup.

> 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
accessible attribute.

I'd just stick the code back in there for now and we'll see what Tres
says.

> 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
BaseRequest.traverse. ;-)

- C