-----BEGIN PGP SIGNED MESSAGE----- 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 ;) Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBR63CrGisBEHG6TARAs2WAJwK2fKlW5KQvPj/LGDT2sGY93q46gCdFRN0 ZsQlTMxX/PHuRN4XZ9Uxq9I= =2gJy -----END PGP SIGNATURE-----