-----BEGIN PGP SIGNED MESSAGE-----
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
You can say that again. My head hurts every time I need to look into
validate() and friends ;)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -