On Wed 30 Jan 2008, titetluc titetluc wrote:
> This would mean that :
> . MySessionModuleVerifyCookie =A0would be first called, verifying if the
> cookie is present and correct
> . If no cookie, then basic authent is requested
> . if basic authent ok, then MySessionModuleGenerateCookie generates a val=

id
> cookie


Sorry, but I haven't really understood what you are trying to achieve. I=20
assume you understand the difference between authentication and authorizati=
on=20
and how they work together. If not try to figure that out first.

1) Perhaps you want to replace a specialized cookie named Authorization hea=
der=20
with a general purpose cookie. (The Authorization header is nothing else th=
an=20
a specialized cookie.)

This can easily be done by forging the Authorization header in a request ph=
ase=20
that comes before (or even in) Auth if the general purpose cookie is there=
=20
and correct. In a phase after Auth (like Fixup) you can then add your cooki=
e=20
if it is not there. Then all your documents would have to be secured by=20
normal Auth-configuration. This can be done with Apache 1.3, 2.0 and 2.2.

2) If you are looking for a more general solution (which I believe you are)=
=20
then for Apache 2.0+ have a look at the Auth*Authoritative directives, e.g.=
=20
AuthBasicAuthoritative. Almost all Auth-modules implement such a directive.=
=20
Your specialized-cookie-module would also have to implement such one. Then=
=20
you can chain Authentication-modules together. If an Authentication module =
is=20
authoritative it returns HTTP_UNAUTHORIZED if the user identity cannot be=20
verified. If it is not authoritative it returns DECLINED instead passing th=
e=20
responsibility to the next authentication module.

3) With Apache 2.2 came authentication providers. They allow to chain=20
different identity verification sources. But all of them are based on the=20
same identity information that is passed in by the client (browser). Among=
=20
geoff's modules is one that provides a perl interface to that.

Torsten