[mp2 ] Request output filters and directories
Hi all, I am one of the developer of LemonLDAP::NG (http://lemonldap-ng.org), a free WebSSO using mod_perl. So to begin, thanks to the mod_perl team for this great product! In our code, we are injecting request output filters with the add_output_filter method. This works well, but we noticed that the filter is never called on directories, only on files: * http://test1.example.com/ -> filter not called * http://test1.example.com/index.pl -> filter called I use ModPerl 2.0.4 for my tests. My Apache configuration is the following: --- ServerName test1.example.com ServerAlias test2.example.com # SSO protection PerlHeaderParserHandler My::Package # DocumentRoot DocumentRoot /usr/local/lemonldap-ng/htdocs/test/ Order deny,allow Allow from all Options +ExecCGI # Perl script (application test is written in Perl) SetHandler perl-script PerlResponseHandler ModPerl::Registry # Directory index DirectoryIndex index.pl index.html --- Can this behaviour comes from the DirectoryIndex and mod_dir? Thanks for your help, Clément OUDOT.
http-authentication on postgresql
Hi There, I have some troubles with the http-authentication using apache2 in combination with postgresql. I used to do it with Apache::AuthenDBI configuring access.conf in the following way: --- AuthName MyDB AuthType Basic PerlAuthenHandler Apache::AuthDBI::authen PerlSetVar Auth_DBI:data_source dbi:Pg:dbname=mydb PerlSetVar Auth_DBI_username me PerlSetVar Auth_DBI_password pw PerlSetVar Auth_DBI_pwd_table MEMBER PerlSetVar Auth_DBI_puid_field EMAILADRES PerlSetVar Auth_DBI_pwd_field PASSWORD PerlSetVar Auth_DBI_encrypted off require valid-user - But with apache2 this results in errors... Can anyone give me a hint? Kind Regards, Michel Jansen
Re: http-authentication on postgresql
Can you give us a hint as to what the errors are? On 22 Mar 2011, at 15:10, Michel Jansen wrote: > Hi There, > > I have some troubles with the http-authentication using apache2 in > combination with postgresql. I used to do it with Apache::AuthenDBI > configuring access.conf in the following way: > > --- > AuthName MyDB > AuthType Basic > PerlAuthenHandler Apache::AuthDBI::authen > PerlSetVar Auth_DBI:data_source dbi:Pg:dbname=mydb > PerlSetVar Auth_DBI_username me > PerlSetVar Auth_DBI_password pw > PerlSetVar Auth_DBI_pwd_table MEMBER > PerlSetVar Auth_DBI_puid_field EMAILADRES > PerlSetVar Auth_DBI_pwd_field PASSWORD > PerlSetVar Auth_DBI_encrypted off > require valid-user > - > > But with apache2 this results in errors... > > Can anyone give me a hint? > > Kind Regards, > > Michel Jansen
Re: http-authentication on postgresql
The Apache::AuthDBI package has changed Checkout the errors below! [Tue Mar 22 16:35:50 2011] [error] [client 192.168.112.1] failed to resolve handler `Apache::AuthDBI::authen': Can't locate Apache/AuthDBI/authen.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl . /etc/apache2) at (eval 2) line 3.\n
Re: http-authentication on postgresql
What version are you using? I'll take a look at this later today if I can find a spare tuit. On Tue, Mar 22, 2011 at 8:37 AM, Michel Jansen wrote: > The Apache::AuthDBI package has changed Checkout the errors below! > > [Tue Mar 22 16:35:50 2011] [error] [client 192.168.112.1] failed to resolve > handler `Apache::AuthDBI::authen': Can't locate Apache/AuthDBI/authen.pm in > @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 > /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 > /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl . > /etc/apache2) at (eval 2) line 3.\n > >
Re: http-authentication on postgresql
Op 22-3-2011 18:59, Fred Moyer schreef: What version are you using? I'll take a look at this later today if I can find a spare tuit. The lastest from cpan!
Re: [mp2 ] Request output filters and directories
On Tuesday, March 22, 2011 15:43:07 Clément OUDOT wrote: > Can this behaviour comes from the DirectoryIndex and mod_dir? I assume you call add_output_filter in My::Package? Now, mod_dir uses subrequests for all of your DirectoryIndex documents. The first it finds, it redirects to using ap_internal_fast_redirect(). This is a very hackish function that tries to magically turn the subreq into the main request. It copies a bunch of values from the subreq into the main req. One of these values is the output filter list. So, after the operation your main req looks mostly like the subreq. Another detail that hits you here is that the HeaderParser phase is called only for the main request. Now put these two together, you start a request for dir/. My::Package installs the output filter in its header parser phase. mod_dir jumps in and issues a subreq for dir/index.pl. The subreq skips the header parser phase. ap_internal_fast_redirect copies the output filter chain (without your filter) from the subreq to the main one. Your registry script index.pl is evaluated but the output filter is gone. What could be done? I think the cleanest way would be to either move My::Package to another phase, fixup for example. If that's not possible you can set a flag in $r->pnotes when the filter in installed. Then you need a fixup handler that looks if the flag is set in $r->main->pnotes and reinstalls the filter if so. Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
Re: [mp2 ] Request output filters and directories
2011/3/22 Torsten Förtsch : > On Tuesday, March 22, 2011 15:43:07 Clément OUDOT wrote: >> Can this behaviour comes from the DirectoryIndex and mod_dir? > > I assume you call add_output_filter in My::Package? Hi, thanks for the answer. Indeed, My::Package call a module like the following, and the add_output_filter method is called in the run() subroutine : http://websvn.ow2.org/filedetails.php?repname=lemonldap&path=%2Ftrunk%2Fmodules%2Flemonldap-ng-handler%2Flib%2FLemonldap%2FNG%2FHandler%2FSecureToken.pm > > Now, mod_dir uses subrequests for all of your DirectoryIndex documents. The > first it finds, it redirects to using ap_internal_fast_redirect(). This is a > very hackish function that tries to magically turn the subreq into the main > request. It copies a bunch of values from the subreq into the main req. One of > these values is the output filter list. So, after the operation your main req > looks mostly like the subreq. > > Another detail that hits you here is that the HeaderParser phase is called > only for the main request. > > Now put these two together, you start a request for dir/. My::Package installs > the output filter in its header parser phase. mod_dir jumps in and issues a > subreq for dir/index.pl. The subreq skips the header parser phase. > ap_internal_fast_redirect copies the output filter chain (without your filter) > from the subreq to the main one. Your registry script index.pl is evaluated > but the output filter is gone. > > What could be done? I think the cleanest way would be to either move > My::Package to another phase, fixup for example. If that's not possible you > can set a flag in $r->pnotes when the filter in installed. Then you need a > fixup handler that looks if the flag is set in $r->main->pnotes and reinstalls > the filter if so. I tried to use PerlFixupHandler instead of PerlHeaderParserHandler, but this changes nothing. I will try to create a specific FixupHandler like you suggested. Clément.