The PerlHeaderParserHandler would look like:
my %config=
(
clientA=>[
...
The problem is this creates a LARGE config file for 10,000+ clients, and
I'm still naive enough to dream big :)
Like I noted in a post to Randal, actually overriding the "_dbi_connect"
sub in the parent was proving to be the problem.
Matisse Enzer, the author of Apache2::AuthCookieDBI told me today that I
could do so using globs, a voodoo I have never explored before...
*Apache2::AuthCookieDBI::_dbi_connect = sub { my stuff... };
This lets me configure the DBI variables on the fly per request which is
a nicer way.
The problem now will be to figure out what problems remain.
Tosh
Torsten Förtsch wrote:
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
--
McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/
