Re: AuthCookieDBI help please.... (more info)
Thanks - I tried that earlier and again at your suggestion - no change in the behavior is noted. This is really frustrating - there doesn't seem to be anything special about this config that should cause me such trouble. I suppose tomorrow I could try the kludge that is recommended in that thread, but given the lack of complaints about this module, I assume it is working for everyone else. Either that or no one is using it...could *that* be true? Is this module is not as useful as it seems at first glance? If it is working for everyone else, I want it to work for me, and I would prefer not to have to track my own patches whenever new versions come out naturally GV At 08:50 AM 10/11/2002 +0200, Vegard Vesterheim wrote: >I had a similar problem a while ago. Check out this thread: > >http://groups.yahoo.com/group/modperl/message/34266 > >- snip - snip - >I discovered the same thing. I think the problem is that the BEGIN >block as written, only considers parameters defined in the *main >server*. So if you have any PerlSetVar in a Virtual Server, it will >not be found. > >A kludgy workaround is to move the PerlSetVar out of any Virtual >Server sections. A better option is to reimplement the mechanism for >populating the SECRET_KEYS hash, so that Virtual Servers are handled >properly. >- snip - snip
Re: AuthCookieDBI help please.... (more info)
On Thu, 10 Oct 2002 17:44:51 -0700 George Valpak <[EMAIL PROTECTED]> wrote:
> At 04:16 PM 10/10/2002 -0700, I wrote:
> >I am having trouble with Apache:AuthCookieDBI. I hope someone here can help because
>I have not been able to find a solution despite extensive searching.
>
>
>
> OK, now I am poking in the code.
>
> I modified the BEGIN section for AuthCookieDBI.pm thusly:
>
> BEGIN {
> my @keyfile_vars = grep {
> $_ =~ /DBI_SecretKeyFile$/
> } keys %{ Apache->server->dir_config() };
> #my changes start here
> my @list = keys %{ Apache->server->dir_config()};
> Apache::log_error("keys:@list");
> Apache::log_error( "all varrs=$_" );
> Apache::log_error( "keyfile_vars=@keyfile_vars" );
> #my changes end here
> foreach my $keyfile_var ( @keyfile_vars ) {
> my $keyfile = Apache->server->dir_config( $keyfile_var );
> my $auth_name = $keyfile_var;
> $auth_name =~ s/DBI_SecretKeyFile$//;
> unless ( open( KEY, "<$keyfile" ) ) {
> Apache::log_error( "Could not open keyfile for $auth_nam
> e in file $keyfile" );
> } else {
> $SECRET_KEYS{ $auth_name } = ;
> close KEY;
> }
> }
> }
>
> and restarted the server. the logs show:
>
>
> [Thu Oct 10 17:34:14 2002] [error] keys:
> [Thu Oct 10 17:34:14 2002] [error] all varrs=
> [Thu Oct 10 17:34:14 2002] [error] keyfile_vars=
> [Thu Oct 10 17:34:14 2002] [notice] Apache/1.3.23 (Unix) (Red-Hat/Linux)
>mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1.0.3 PHP/4.1.2 mod_perl/1.26 configured -- resuming
>normal operations
> [Thu Oct 10 17:34:14 2002] [notice] suEXEC mechanism enabled (wrapper:
>/usr/sbin/suexec)
> [Thu Oct 10 17:34:14 2002] [notice] Accept mutex: sysvsem (Default: sysvsem)
>
> This to me indicates that the call to Apache->server->dir_config() is not returning
>anything at all. A quick look a the eagle book, p 456 does not explain to me why
>that should beany thoughts?
>
I had a similar problem a while ago. Check out this thread:
http://groups.yahoo.com/group/modperl/message/34266
- snip - snip -
I discovered the same thing. I think the problem is that the BEGIN
block as written, only considers parameters defined in the *main
server*. So if you have any PerlSetVar in a Virtual Server, it will
not be found.
A kludgy workaround is to move the PerlSetVar out of any Virtual
Server sections. A better option is to reimplement the mechanism for
populating the SECRET_KEYS hash, so that Virtual Servers are handled
properly.
- snip - snip -
--
Vegard Vesterheim : Phone: +47 73 55 79 12
UNINETT : Fax: +47 73 55 79 01
N-7465 Trondheim, NORWAY: Email: [EMAIL PROTECTED]
Re: [OT] migrating from Apache to iPlanet; any mod_perl counterpart?
On Thu, 2002-10-10 at 14:43, Paul wrote: > > There's nothing you've mentioned so far that requires Java. It would > > be much faster to port it to FastCGI or the like. > > I just meant that iPlanet's internal API was probably going to require > Java or C, and not Perl. FastCGI and PersistentPerl are both working equivalents to mod_perl with similar capabilities and performance. They should work just fine with iPlanet. > I can redo most of it as CGI if necessary, but > some of that will require slieght-of-code like embedding data in > cookies or hidden form elements I don't see why that would be any different from what you currently have. Any state mechanism requires cookies, URLs, or hidden form values for maintaining at least a unique ID on the client side. There is no other way to do it. > I just prefer having all the data from the engine available > from the request object, and I'm gonna miss that. Again, I don't understand what you think you're going to lose. All the basic data available under mod_perl is available under everything else as well, albeit with a slightly different API. - Perrin
Re: AuthCookieDBI help please.... (more info)
At 04:16 PM 10/10/2002 -0700, I wrote:
>I am having trouble with Apache:AuthCookieDBI. I hope someone here can help because I
>have not been able to find a solution despite extensive searching.
OK, now I am poking in the code.
I modified the BEGIN section for AuthCookieDBI.pm thusly:
BEGIN {
my @keyfile_vars = grep {
$_ =~ /DBI_SecretKeyFile$/
} keys %{ Apache->server->dir_config() };
#my changes start here
my @list = keys %{ Apache->server->dir_config()};
Apache::log_error("keys:@list");
Apache::log_error( "all varrs=$_" );
Apache::log_error( "keyfile_vars=@keyfile_vars" );
#my changes end here
foreach my $keyfile_var ( @keyfile_vars ) {
my $keyfile = Apache->server->dir_config( $keyfile_var );
my $auth_name = $keyfile_var;
$auth_name =~ s/DBI_SecretKeyFile$//;
unless ( open( KEY, "<$keyfile" ) ) {
Apache::log_error( "Could not open keyfile for $auth_nam
e in file $keyfile" );
} else {
$SECRET_KEYS{ $auth_name } = ;
close KEY;
}
}
}
and restarted the server. the logs show:
[Thu Oct 10 17:34:14 2002] [error] keys:
[Thu Oct 10 17:34:14 2002] [error] all varrs=
[Thu Oct 10 17:34:14 2002] [error] keyfile_vars=
[Thu Oct 10 17:34:14 2002] [notice] Apache/1.3.23 (Unix) (Red-Hat/Linux)
mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1.0.3 PHP/4.1.2 mod_perl/1.26 configured -- resuming
normal operations
[Thu Oct 10 17:34:14 2002] [notice] suEXEC mechanism enabled (wrapper:
/usr/sbin/suexec)
[Thu Oct 10 17:34:14 2002] [notice] Accept mutex: sysvsem (Default: sysvsem)
This to me indicates that the call to Apache->server->dir_config() is not returning
anything at all. A quick look a the eagle book, p 456 does not explain to me why that
should beany thoughts?
GV
AuthCookieDBI help please....
I am having trouble with Apache:AuthCookieDBI. I hope someone here can help because I have not been able to find a solution despite extensive searching. Config overview: RH 7.3 Apache/1.3.23 (Unix) (Red-Hat/Linux) mod_perl 1.26 Apache::AuthCookieDBI-1.19 I can bring up the login form provided with the module, but it always returns the login-failed form and I am not sure why. The log file returns: [Thu Oct 10 15:28:27 2002] [error] access to /LOGIN failed for sdn-ar-019casfrmp184.dialsprint.net, reason: Apache::AuthCookieDBI: didn't have the secret key for auth realm dev2 [Thu Oct 10 15:28:28 2002] [error] access to /signmanage/ failed for sdn-ar-019casfrmp184.dialsprint.net, reason: Apache::AuthCookieDBI: didn't the secret key from for auth realm dev2 I see in the documentation at http://search.cpan.org/author/CROMIS/Apache-AuthCookieDBI-1.19/AuthCookieDBI.pm that heat secret key needs to be listed in the httpd.conf before the PerlModule, which I believe I am doing (see below). Other than that, I can't find any additional tips. This guy seemed to have a similar issue, but his SecretKey line was in the wrong place it appears: http://groups.google.com/groups?q=%22secret+key+from%22+%22for+auth+realm%22&hl=en&lr=&ie=UTF-8&oe=utf-8&selm=76cfba01.0202221058.3b319bdb%40posting.google.com&rnum=1 Below is the relevant part of my config. Thanks for your help! GV --- DocumentRoot /home/websites/dev2 ServerName dev2.somewhere.com DirectoryIndex index.html PerlSetVar dev2DBI_SecretKeyFile /home/websites/dev2/signmanage/secretkey.txt PerlModule Apache::AuthCookieDBI PerlSetVar dev2Path / PerlSetVar dev2LoginScript /signmanage/login.pl PerlSetVar dev2DBI_DSN "dbi:Pg:dbname=users" PerlSetVar dev2DBI_User "pguser" AuthName dev2 AuthType Apache::AuthCookieDBI PerlAuthenHandler Apache::AuthCookieDBI->authenticate PerlAuthzHandler Apache::AuthCookieDBI->authorize Require valid-user AuthName dev2 AuthType Apache::AuthCookieDBI PerlAuthenHandler Apache::AuthCookieDBI->authenticate PerlAuthzHandler Apache::AuthCookieDBI->authorize Require valid-user SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI :
Re: [OT] migrating from Apache to iPlanet; any mod_perl counterpart?
--- Perrin Harkins <[EMAIL PROTECTED]> wrote: > Paul wrote: > > The problem isn't so much the registry as the API. > > Any use of the Apache API would have to be rewritten. There is no > way around that. That's what I figured. > > I don't know how I'm going to do all that with iPlanet/LDAP without > > a lot of recoding, probably in Java. :( > > There's nothing you've mentioned so far that requires Java. It would > be much faster to port it to FastCGI or the like. I just meant that iPlanet's internal API was probably going to require Java or C, and not Perl. I can redo most of it as CGI if necessary, but some of that will require slieght-of-code like embedding data in cookies or hidden form elements &c though I do that some already anyway. I just prefer having all the data from the engine available from the request object, and I'm gonna miss that. Still, the SUN rep talks a good game, and my paycheck demands that I play the game the way the big bosses want. As an aside, this should begin next month. Would the list be interested in a running commentary of how things are done on the new one, or would that be too much spammy line-noise? __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com
Re: [OT] migrating from Apache to iPlanet; any mod_perl counterpart?
Paul wrote: > The problem isn't so much the registry as the API. Any use of the Apache API would have to be rewritten. There is no way around that. > I don't know how I'm going to do all that with iPlanet/LDAP without a > lot of recoding, probably in Java. :( There's nothing you've mentioned so far that requires Java. It would be much faster to port it to FastCGI or the like. - Perrin
Re: [OT] migrating from Apache to iPlanet; any mod_perl counterpart?
--- Perrin Harkins <[EMAIL PROTECTED]> wrote: > Perrin Harkins wrote: > > Paul wrote: > > > >> I know there are servlets, but I was led to believe that I would > >> almost be able to drop my mod_perl modules into the iPlanet server, > >> as if it has some equivelent functionality. If so, I can't find any > >> evidence of it, and I'm rather skeptical. > > > > I think your only hope is FastCGI, or PerlEx if you're running it > > on Windows. > > Wait, there is also PersistentPerl (formerly SpeedyCGI), and Matt's > PPerl. Both on CPAN. > - Perrin The problem isn't so much the registry as the API. I've done a lot of server customization, such as embedding the MySQL database for flexible, customizable password access and such, including: - automatic forwarding to SLL at the same document URL (new protocol) - making the server restricted by *default*, so only nonrestricted directories need to be specified (there are few) - allowing .htaccess files to specify individual files and subdirectories with alternate passwords etc. I don't know how I'm going to do all that with iPlanet/LDAP without a lot of recoding, probably in Java. :( __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com
Re: [OT] migrating from Apache to iPlanet; any mod_perl counterpart?
Perrin Harkins wrote: > Paul wrote: > >> I know there are servlets, but I was led to believe that I would almost >> be able to drop my mod_perl modules into the iPlanet server, as if it >> has some equivelent functionality. If so, I can't find any evidence of >> it, and I'm rather skeptical. > > I think your only hope is FastCGI, or PerlEx if you're running it on > Windows. Wait, there is also PersistentPerl (formerly SpeedyCGI), and Matt's PPerl. Both on CPAN. - Perrin
Re: [OT] migrating from Apache to iPlanet; any mod_perl counterpart?
Paul wrote: > I know there are servlets, but I was led to believe that I would almost > be able to drop my mod_perl modules into the iPlanet server, as if it > has some equivelent functionality. If so, I can't find any evidence of > it, and I'm rather skeptical. I think your only hope is FastCGI, or PerlEx if you're running it on Windows. - Perrin
Re: [OT] migrating from Apache to iPlanet; any mod_perl counterpart?
On Wed, Oct 09, 2002 at 02:43:18PM -0700, Paul wrote: > The company is making us migrate (some baloney about being legally > vulnerable because we're using open source), and I've got to convert a > nice, simple, efficient Apache/mod_perl/MySQL solution to iPlanet/LDAP. > > Am I looking at a complete redesign here? That totally sux0rs :( Maybe you should try hitting the powers-that-be with a large 2x4" clue-stick? Or mention that other huge businesses such as imdb, banner ad companies, etc use it and are still sucessful and raking in the cash. A long shot but. alan -- Alan "Arcterex" <[EMAIL PROTECTED]> -=][=- http://arcterex.net "I used to herd dairy cows. Now I herd lusers. Apart from the isolation, I think I preferred the cows. They were better conversation, easier to milk, and if they annoyed me enough, I could shoot them and eat them." -Rodger Donaldson
Re: How would you organize custom logging?
On Thu, 10 Oct 2002, Ged Haywood wrote:
> Hi there,
>
> On Thu, 10 Oct 2002, Marcin Kasperski wrote:
> > >
> > > I am to provide some custom logging in my mod_perl application.
> [snip]
>
> and On Thu, 10 Oct 2002, Victor Tsang wrote:
> >
> > Instead of developing something new, how about extending the
> > combined/common log format?
>
> Or you could investigate the various logging modules already in
> existence. Look in the mod-perl Cookbook chapters 16, the Eagle Book,
> the Guide (see the mod_perl home page for details) and on CPAN.
>
> > > how should I pass data between handlers - just stick to some perl
> > > global variable or use pnotes?
>
> See for example 8.11 in the Cookbook.
>
> > > 3) Are there any tools of 'gather logs from multiple machines to the
> > > central location' you would recommend?
>
> The database approach would probably be easiest.
Easy but totally unscalable unless you make it not easy, with caching,
cache flushing to account for network hiccups, etc. etc.
Eventually we wrote a system with a logging daemon on the server and
clients on the clients. The latter took logging data from apache with a
custom handler and then sent it off to the daemon using some of the
techniques I mentioned above.
- nick
Nick Tonkin {|8^)>
Re: [mp2.0] wrong crypt behavior
I missed part of this thread, but I have my doubts about perl's internal
crypt working correctly in a threaded environment. Using 5.8.0 threaded
for the x86 platform / mod_perl 1.27 that on an uniprocessor machine it
would produce correct results most of the time, but on a multiprocessor
machine it would consistantly produce bad results. After battling with it
for awhile and not having time to get correct data to produce a bug report
- I switched to the pure perl version Crypt::UnixCrypt which works quite
well across the board. *sigh*
On Thu, 10 Oct 2002, Ask Bjoern Hansen wrote:
> On Fri, 6 Sep 2002, [iso-8859-2] Tomá¹ Procházka wrote:
>
> > Problem: Sometimes, although user entered correct password, is
> > authentication rejected. I tried logging values of $real_pass and
> > $test_pass and they differed. When I add line
>
> Did anyone figure this out?
>
> The following content handler gives a different output everytime I
> restart my threaded mod_perl 2.0. Dm8yjkphWW352 is the correct
> answer; I get that after about a third of the restarts.
>
> - ask
>
>
> package Develooper::MT::Test;
> use strict;
> use warnings;
>
> use Apache::RequestRec ();
> use Apache::RequestIO ();
>
> use Apache::Const -compile => 'OK';
>
> my $clear = "foo";
> my $salt = "Dm";
>
> sub handler {
> my $r = shift;
> $r->content_type('text/plain');
> my $crypted = crypt $clear, $salt;
> $r->print("crypt $clear, $salt = $crypted");
> return Apache::OK;
> }
>
> 1;
>
>
--
//\\
|| D. Hageman<[EMAIL PROTECTED]> ||
\\//
Re: How would you organize custom logging?
Marcin Kasperski wrote: > I am to provide some custom logging in my mod_perl > application. Omitting some unnecessary details, I need to store some > information after processing each request, putting this info into some > central log (be it file or database) common for all apache processes > and (if possible) common for multiple machines. > > I would like to ask for any suggestions/hints/patterns/... but there > are also some specific qustions: > > 1) Apache somehow gathers notes from multiple processes into single > access.log and error.log. Is it possible to reuse this functionality > somehow for writing my custom information somewhere else? Considering > such functionality is already present I would not like to reimplement > logic protecting from simultaneous write from multiple processess... you can write the information anywhere you want. not reinventing the wheel is usually preferred, though :) the access_log is much easier to handle than the error_log, fwiw. > > 2) Looking at the name, seems it is LogHandler where custom logging > should take place. But does it really give real advantage over just > logging on the end of PerlHandler? you can pretty much shove just about everything into the PerlHandler if you wanted to - that's what most other application environments end up doing anyway (CGI, ASP, servlets...). the cool thing about mod_perl is that you get access to the various apache phases, and utilizing them for what they were designed for makes your application cleaner. > If so, how should I pass data > between handlers - just stick to some perl global variable or use > pnotes? pnotes is one way to do it. the approach victor described in his email is another. the cookbook chapter on logging has some ideas that might suit you (including victor's in 16.4) http://www.modperlcookbook.org/chapters/ch16.pdf > > 3) Are there any tools of 'gather logs from multiple machines to the > central location' you would recommend? mod_log_spread appears to be very popular, though I haven't used it myself. HTH --Geoff
Re: How would you organize custom logging?
Hi there, On Thu, 10 Oct 2002, Marcin Kasperski wrote: > > > > I am to provide some custom logging in my mod_perl application. [snip] and On Thu, 10 Oct 2002, Victor Tsang wrote: > > Instead of developing something new, how about extending the > combined/common log format? Or you could investigate the various logging modules already in existence. Look in the mod-perl Cookbook chapters 16, the Eagle Book, the Guide (see the mod_perl home page for details) and on CPAN. > > how should I pass data between handlers - just stick to some perl > > global variable or use pnotes? See for example 8.11 in the Cookbook. > > 3) Are there any tools of 'gather logs from multiple machines to the > > central location' you would recommend? The database approach would probably be easiest. 73, Ged.
Re: [mp2.0] wrong crypt behavior
On Thu, 10 Oct 2002, Ask Bjoern Hansen wrote:
> > Problem: Sometimes, although user entered correct password, is
> > authentication rejected. I tried logging values of $real_pass and
> > $test_pass and they differed. When I add line
>
> Did anyone figure this out?
>
> The following content handler gives a different output everytime I
> restart my threaded mod_perl 2.0. Dm8yjkphWW352 is the correct
> answer; I get that after about a third of the restarts.
FWIW, the following test program (also with 5.8.0 with threads
(duh)) doesn't seem to have a problem with crypt.
use threads;
for (1..50) { threads->create("test"); }
map { $_->join } grep { $_->tid != threads->tid } threads->list;
sub test {
my $salt= "Dm";
my $clear = "foo";
for (1..1) {
my $crypted = crypt($clear,$salt);
print "$crypted\n" if $crypted ne "Dm8yjkphWW352";
}
}
- ask
--
ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: [mp2.0] wrong crypt behavior
On Fri, 6 Sep 2002, [iso-8859-2] Tomá¹ Procházka wrote:
> Problem: Sometimes, although user entered correct password, is
> authentication rejected. I tried logging values of $real_pass and
> $test_pass and they differed. When I add line
Did anyone figure this out?
The following content handler gives a different output everytime I
restart my threaded mod_perl 2.0. Dm8yjkphWW352 is the correct
answer; I get that after about a third of the restarts.
- ask
package Develooper::MT::Test;
use strict;
use warnings;
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::Const -compile => 'OK';
my $clear = "foo";
my $salt = "Dm";
sub handler {
my $r = shift;
$r->content_type('text/plain');
my $crypted = crypt $clear, $salt;
$r->print("crypt $clear, $salt = $crypted");
return Apache::OK;
}
1;
--
ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
