Re: mod_perl waters too deep

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/