On Apr 21, 2009, at 10:39 AM, Toby Blake wrote:
>> Hmm. I've had a couple other reports about similar problems with
>> directives which should work in location blocks. I'll see what I can
>> find out what's going on, and release 3.0.2. In the meantime, I hope
>> this workaround helps.
>
> Great, thanks, but not ideal for the longer term. Also I can leave v2
> filters running against a v3.0 server for the moment, so I can
> preserve per-location settings.
>
> If I can provide any more debugging information on this, let me know.
> e.g. backtraces, etc.
Kevin Coffman of Umich ran into this problem while working with proxy
cookies. He tracked it back to a long standing bug in mod_cosign,
which is that proxy cookies and tickets are only retrieved if the
filter believes the current request is the first authenticated visit
by the user. Cosign 3 exercises the bug because of the new validation
URL, which is always visited before redirection to the service URL. If
CosignGetProxyCookies or CosignGetKerberosTickets is set in a
Directory or Location context, they will not be retrieved because the
handler configuration is in its own Location context. I'm working on a
fix.
The same problem does exist in the legacy filters, though. If you have
this setup:
<Location /gateway>
CosignProtected On
</Location>
<Location /filespace>
CosignProtected On
CosignGetKerberosTickets On
</Location>
and you visit the /gateway URI first, you won't have tickets when you
visit the /filespace URI. If you visit /filespace first, you'll get
the tickets. But those tickets are also available to the /gateway URI:
mod_cosign will read the cookie, observe that there's a value for the
kerberos ticket path, and set the KRB5CCNAME environment.
Toby, what's the value for you in having CosignGetKerberosTickets
available in Location or Directory contexts?
andrew
|