[Zope-dev] 2.7 branch: attribute permission problems

Richard Jones richard at commonground.com.au
Tue Sep 14 22:49:38 EDT 2004

Hash: SHA1

On Wed, 15 Sep 2004 12:36 pm, Chris McDonough wrote:
> > Yep, that's the situation. It appears to look for the security assertions
> > for "secure_url" on A instead of B. Note that "secure_url" is an
> > attribute of B.
> 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.

I'm a little confused about why I'm the only person seeing this, BTW...

> 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 ;)

Version: GnuPG v1.2.4 (GNU/Linux)


More information about the Zope-Dev mailing list