On Monday 14 December 2009 16:14:31 Tosh Cooey wrote:
> You may have seen my other recent questions to the list this month, the
> gist of which is:
>
> I want to setup an application for multiple clients, each of whom have
> their own users.
>
> http://www.site.com/clientA/application.pl
> http://www.site.com/clientB/application.pl
> http://www.site.com/clientX/application.pl
>
> So the users of "clientA" log in to
> http://www.site.com/clientA/application.pl and are authenticated with
> Apache2::AuthCookieDBI
>
> Now the directories clientA, clientB, etc. do not exist, I'm using
> mod_rewrite to sort that out, and here starts my problems. First I'm
> lost with authenticating since there's no "real" resource to
> authenticate against, but I seem to have solved that by forcing
> authentication against all *.pl files which luckily do exist ;)
>
> It gets more complicated later because some URLs like
> http://www.site.com/clientA/iCal can't use session cookies but have to
> use BASIC AUTH, and other *.pl files can't have any authentication
> applied against them.
>
> I thought I could solve this by writing a MyAuthCookieDBI.pm but this
> also isn't working out. For example MyAuthCookieDBI is an almost-empty
> child. The parent (Apache2::AuthCookieDBI) has a function
> _dbi_connect() which manages all the database connecting, but I can't
> overwrite that function, even if MyAuthCookieDBI is the calling object
> the function from Apache2::AuthCookieDBI always gets called rather than
> the overridden function in my object.
>
> That's kind of the tip of things, basically I'm realizing that I need
> professional help with this task before I end up requiring professional
> help for my nerves!
>
> So if anyone can help with this then please contact me offlist with terms.
From reviewing what you have posted I take it the main problem is you have a
huge number of clients and don't want to write a .htaccess file for each one,
right?
There are 2 ways to solve this. 1) generate the httpd.conf on startup from the
client database adding a <Location> block for each one. That means you'd have
to restart apache for each new client.
The second way is to write a simple and short (3-4 lines of code) modperl-
handler that adds the right configuration directives to the request depending
on the url. The trick when to do that within the request cycle.
Auth-directives are applied just after the HeaderParser phase. So, the last
chance to add authentication stuff is the header parser phase. Unfortunately
this phase is skipped for subrequests. So, if you want to catch subrequests as
well MapToStorage is the only way. But it also has its tweaks. So, let's
assume you use the HeaderParser phase for a start.
The PerlHeaderParserHandler would look like:
my %config=
(
clientA=>[
'AuthType Apache2::AuthCookieDBI',
'AuthName WhatEver',
'PerlAuthenHandler Apache2::AuthCookieDBI->authenticate',
'PerlAuthzHandler Apache2::AuthCookieDBI->authorize',
'require valid-user',
'PerlSetVar WhatEver... ...',
...
],
clientB=>...
...
);
sub ... {
my ($r)=...@_;
return Apache2::Const::DECLINED unless $r->uri=~m!/([^/]+)!;
$r->add_config($config{$1});
return Apache2::Const::DECLINED;
}
What now happens is Apache reads in the request then just before deciding if
authentication is needed the HeaderParser handler jumps in, looks at the URI
and adds the needed configuration stuff.
Perhaps you have a look at my Apache2::Translation on CPAN. I think it's a
very handy module for complicated configurations. I wouldn't configure an
apache without it anymore and I know some other folks who wouldn't either.
Torsten
