hi,
I'm having a big headache with a complex Auth scheme I must implement.
It seems I'll have to code quite a bit anyway, but I'm pondering the
options I have. Currently, the server setup looks like this:
- apache.plain : running at port 80, serving all static content and
proxying (with mod_rewrite + mod_proxy) all dynamic requests to the
backend daemons.
- apache.perl : running at port 1800, serving all Apache::Registry and
HTML::Embperl content. Few children.
- apache.php : running at port 1801, serving PHP pages. Few children.
Now, I'm developing a complex website full of services. Some of these
services (webmail and various groupware apps) are provided by a patched
TWIG (a PHP app). All the other services will be provided by mod_perl
scripts. The user will be browsing across these services, unaware of the
different platforms I'm implementing for each service, but I need to
present one single point of authentication, and then share that
information across the 3 apache servers.
The authentication will be done against a user/pw pair that is in a
mySQL. This same usr/pw auth data is valid against the IMAP server I'm
using. TWIG in fact can be configured to authorize against the IMAP
server.
TWIG will track the user with cookies or encoding each link with a
token. I cannot follow the 'token' path because then I cannot link
'into' a TWIG page from a static page. So I'm stuck with using TWIG's
cookies, although right now I'm having problems as they seem to dislike
the proxying ...
The TWIG Auth interface can be chosen to be FORMS, so I can fake it
POSTing or GETting the usr/pw pair at the right time. Also, if I can get
the information there (in %ENV, for instance), I may be able to hack
TWIG into believing the user has authenticated.
Possible Solutions I'm pondering (and I do need some more!@):
A - Authenticate at the proxy, against a DBM build from the mySQL table.
Then pass the Auth information to the backend servers, maybe encoding it
in the url with mod_rewrite.
B - Authenticate at TWIG, let it set its cookie, and use TWIG's cookie.
Of course, it menas I'll have to understand TWIG's cookie, and that it
may be impossible to use if the cookie uses some kind of 'secret' (on
the other hand, TWIG uses mySQL tables to keep state, so I might learn
to read TWIG's mySQL tables).
C - Authenticate at mod_perl and learn to fake TWIG's cookie. A bit more
complex, but basicallythe same as B.
D - Build one behemoth of an apache, (maybe discard all proxying) and
build mod_perl + mod_php. Then I can set the ENV vars from mod_perl,
authenticate using Apache::AuthCookie and pick up the Auth info in TWIG
just from the ENV.
whew! a long post indeed. Well, those are my draft ideas. Anyone care
to comment before I choose one at random and start coding headlong?
martin
