Re: About PerlLogHandler phase
On Mon, 11 Feb 2002, Paul Lindner wrote: On Mon, Feb 11, 2002 at 06:31:25PM -0800, Randy J. Ray wrote: * If I install a handler for PerlLogHandler, does the normal logging still take place? Is it a function of whether my handler returns OK, DECLINED, etc.? As far as I know return codes are ignored. This means that all logging (and cleanup) handlers are called for each request. Unless, I'm pretty sure, the PerlLogHandler returns SERVER_ERROR, in which case log handling will stop. The client won't see the 'error' because it's already received all the content. dave
[Q] Apache::File-new
Hi, I searched in the book, I searched in the FAQs - no I ask u: Does Apache::File-new start a subrequest? There are some mystical lines in my rewrite_log, which might come from there. Thanx a lot Martin
Re: mod_perl + UNIVERSAL
The thing is I am getting some weird behaviour where one application seems to be getting code from the other. In theory this isn't possible with the separated namespaces. I suspect my UNIERVSAL use is the problem. Can anyone verify this? Is it a known problem? Is there any way around it? To my knowledge, the only namespace which is separated is package main. I don't know about you guys, but I think it would be great if mod_perl could be as painless as mod_php. Don't get me wrong, I think that PHP as a language is absolutely fubar, however mod_php is fast, secure, isp friendly and does not have so many problems as mod_perl. A list of things I've noticed: * If you have two *different* modules which have the same name, then either one, or the other is loaded in memory, never both. This is dead annoying. I think Perl standard modules + CPAN modules should be shared, other modules which are specific to a given script should not. * Global variables should be reinitialized on each request. Or at least if we want them to be persistent we do not want them to be shared with different scripts on different virtual hosts! * Perl garbage collector should be smarter (okay, that may not be a mod_perl issue). C geeks out there, ain't it possible to compile a version of Perl with a better GC? * Despite numerous heroic efforts, HTTP HEAD requests are still screwed! Apache::Registry serves HEAD + Body, and Geoffrey's Apache::HEADRegistry doesn't work with redirects and 404's (I get like two headers and 3 bodies for 404's. Now that's verbose :-)) These are the - painful - issues I discovered during the last 6 month of intensive mod_perl coding. I hope they'll be fixed at some point because mod_perl could be so popular if they were! Allright I'll stop whining and go back to some coding ;-) Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 221 4968 VISIT HTTP://WWW.MKDOC.COM
Re: mod_perl + UNIVERSAL
Jean-Michel Hiver wrote: [snip] A list of things I've noticed: * If you have two *different* modules which have the same name, then either one, or the other is loaded in memory, never both. This is dead annoying. I think Perl standard modules + CPAN modules should be shared, other modules which are specific to a given script should not. And who's to say that a custom module that you write can't end up on CPAN??? Or even as a Standard module? There may be ways of fiddling with @INC to do what you want, but it would be much easier if you, the developer, took care to make unique namespaces for your different projects... * Global variables should be reinitialized on each request. Or at least if we want them to be persistent we do not want them to be shared with different scripts on different virtual hosts! If you want them reset each time, then reset them to undef manually. The alternative is having Apache reload the entire module from scratch on every request - and then you may as well be using mod_cgi.. [snip] * Despite numerous heroic efforts, HTTP HEAD requests are still screwed! Apache::Registry serves HEAD + Body, and Geoffrey's Apache::HEADRegistry doesn't work with redirects and 404's (I get like two headers and 3 bodies for 404's. Now that's verbose :-)) No real mod_perl problem on that - that's a problem (or maybe intentional functionality?) in Apache::Registry and Apache::HEADRegistry... These are the - painful - issues I discovered during the last 6 month of intensive mod_perl coding. I hope they'll be fixed at some point because mod_perl could be so popular if they were! I dunno... I think that the main reason mod_perl isn't as popular as mod_php is because PHP is SSI based, making it more appetizing to lots of developers who don't have such good access to the server, or who don't want to understand the internals of Apache module writing (remember that that's the real point of mod_perl: to write Apache modules in Perl instead of C), whereas mod_perl means pre-writing modules and having to reload the server (or use a top-heavy module like Apache::StatInc) every time you want to change your code. Of course, that's the power of mod_perl over mod_php. And I know that personally, it's why I use it. As to the non-ISP friendliness disadvantage, that's a critical issue, but I think it's being re-analyzed for mod_perl 2.0 Just my two agorot (a bit less than $0.005 now, I think, although due to that the smallest currency here is actually _5_ agorot :-) ) Issac
Re: mod_perl + UNIVERSAL
On Tue, 12 Feb 2002 14:15:37 +1100
Morton-Allen, Matthew [EMAIL PROTECTED] wrote:
However both applications make use of the UNIERVSAL package to create
universally accessible methods (to return the current database handle for
example) within the application.
You don't need UNIVERSAL for the purpose. Try import().
package Foo;
our @ISA = qw(Exporter);
our @EXPORT = qw(get_dbh);
sub get_dbh { ... }
package main;
use Foo; # will import get_dbh()
my $dbh = get_dbh;
--
Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: mod_perl + UNIVERSAL
* If you have two *different* modules which have the same name, then either one, or the other is loaded in memory, never both. This is dead annoying. I think Perl standard modules + CPAN modules should be shared, other modules which are specific to a given script should not. And who's to say that a custom module that you write can't end up on CPAN??? Or even as a Standard module? There may be ways of fiddling with @INC to do what you want, but it would be much easier if you, the developer, took care to make unique namespaces for your different projects... Consider this. I develop a piece of software in Perl which is quite big. Therefore it's split into a horde of modules. Now do these modules changes between versions? Yes (bug fixes, improvements, API changes, etc). Do the modules name change? Nope! As a result I had to amend the software so that it can run multiple websites. But then if there is a need to change the logic of just one site I can't just go and change one module because it would change it for everything else. In other words it'd be nice to be able to run different versions of the same software for different websites on the same server (via virtual hosts). And that doesn't work. Besides this: with @INC to do what you want, but it would be much easier if you, the developer, took care to make unique namespaces for your different projects... is highly bullshit. I am not the only developer on the planet. For instance there is a CPAN module called HTML::Tree. But there is also another module on the web called HTML_Tree, which installs itself as HTML::Tree. The developer does not want to rename his module (I understand that). Even if I install / compile the module locally, mod_perl is going to screw everything up! Great! * Global variables should be reinitialized on each request. Or at least if we want them to be persistent we do not want them to be shared with different scripts on different virtual hosts! If you want them reset each time, then reset them to undef manually. I think this is wrong. Variables should be reinitialized by default, or persistent if specified otherwise in some config file. * Despite numerous heroic efforts, HTTP HEAD requests are still screwed! Apache::Registry serves HEAD + Body, and Geoffrey's Apache::HEADRegistry doesn't work with redirects and 404's (I get like two headers and 3 bodies for 404's. Now that's verbose :-)) No real mod_perl problem on that - that's a problem (or maybe intentional functionality?) in Apache::Registry and Apache::HEADRegistry... intentional functionality. I though that bugs were called features, but this is even better. I'll have to remember this one :- don't want to understand the internals of Apache module writing (remember that that's the real point of mod_perl: to write Apache modules in Perl instead of C), whereas mod_perl means pre-writing True, however the real point of Apache::Registry is to run unaltered CGI scripts under mod_perl and it just doesn't work properly does it? Of course, that's the power of mod_perl over mod_php. And I know that personally, it's why I use it. As to the non-ISP friendliness disadvantage, that's a critical issue, but I think it's being re-analyzed for mod_perl 2.0 Do you know where to find mod_perl 2 related info on the web? I'd be interested in knowing what's it gonna be. Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 221 4968 VISIT HTTP://WWW.MKDOC.COM
Re: mod_perl + UNIVERSAL
Jean-Michel Hiver wrote: * If you have two *different* modules which have the same name, then either one, or the other is loaded in memory, never both. This is dead annoying. I think Perl standard modules + CPAN modules should be shared, other modules which are specific to a given script should not. And who's to say that a custom module that you write can't end up on CPAN??? Or even as a Standard module? There may be ways of fiddling with @INC to do what you want, but it would be much easier if you, the developer, took care to make unique namespaces for your different projects... Consider this. I develop a piece of software in Perl which is quite big. Therefore it's split into a horde of modules. Now do these modules changes between versions? Yes (bug fixes, improvements, API changes, etc). Do the modules name change? Nope! As a result I had to amend the software so that it can run multiple websites. But then if there is a need to change the logic of just one site I can't just go and change one module because it would change it for everything else. In other words it'd be nice to be able to run different versions of the same software for different websites on the same server (via virtual hosts). And that doesn't work. TMTOWTDI: Make all of your global (base) functionality wrapped into some OO Perl module, and then if you need to change specific behavior for certain apps, you can easily subclass it. If the main functionality has to be changed, change the parent object; if it has to be changed for a specific web-app, dump it into the inheritted class. That's one solution, and I'm sure there are others... Besides this: with @INC to do what you want, but it would be much easier if you, the developer, took care to make unique namespaces for your different projects... is highly bullshit. I am not the only developer on the planet. For instance there is a CPAN module called HTML::Tree. But there is also another module on the web called HTML_Tree, which installs itself as HTML::Tree. The developer does not want to rename his module (I understand that). Even if I install / compile the module locally, mod_perl is going to screw everything up! Great! That's the developer's fault. I'm sorry. But that's why you're _supposed_ to check in with [EMAIL PROTECTED] before deciding on your modules namespaces. Just because _another_ developer is using a taken namespace doesn't make it right enough that special pains have to be made to get around it. And if they _did_, that would be a Perl problem, not a mod_perl related issue! For example, how would you get the CPAN Html::Tree to work in the same script as this other HTML::Tree? You couldn't, because the Perl interpreter wouldn't know what to do with it. Same here! * Global variables should be reinitialized on each request. Or at least if we want them to be persistent we do not want them to be shared with different scripts on different virtual hosts! If you want them reset each time, then reset them to undef manually. I think this is wrong. Variables should be reinitialized by default, or persistent if specified otherwise in some config file. What if I _want_ a variable that stays consistant across a specific child process' lifetime? Right now, a way _exists_ of resetting variables, but how would you propose to keep them static if your idea was implemented? * Despite numerous heroic efforts, HTTP HEAD requests are still screwed! Apache::Registry serves HEAD + Body, and Geoffrey's Apache::HEADRegistry doesn't work with redirects and 404's (I get like two headers and 3 bodies for 404's. Now that's verbose :-)) No real mod_perl problem on that - that's a problem (or maybe intentional functionality?) in Apache::Registry and Apache::HEADRegistry... intentional functionality. I though that bugs were called features, but this is even better. I'll have to remember this one :- ;-) don't want to understand the internals of Apache module writing (remember that that's the real point of mod_perl: to write Apache modules in Perl instead of C), whereas mod_perl means pre-writing True, however the real point of Apache::Registry is to run unaltered CGI scripts under mod_perl and it just doesn't work properly does it? No. That's Apache::PerlRun. Apache::Registry usually needs some tweaking to run properly. There's plenty of information about that in the guide under the HUGE portion devoted to CGI_to_mod_perl_porting (or even in the special manpage under the same name). Of course, that's the power of mod_perl over mod_php. And I know that personally, it's why I use it. As to the non-ISP friendliness disadvantage, that's a critical issue, but I think it's being re-analyzed for mod_perl 2.0 Do you know where to find mod_perl 2 related info on the web? I'd be interested in knowing what's it gonna be. Not really sure. I asked about that and got the current state of the mod_perl 2 docs from CVS, but I, too,
Re: [Q] Apache::File-new
Martin Haase-Thomas wrote: Hi, I searched in the book, I searched in the FAQs - no I ask u: Does Apache::File-new start a subrequest? no. it is merely a layer over Perl's file IO methods (Perl_do_open from what I can see). There are some mystical lines in my rewrite_log, which might come from there. that seems strange. maybe post the lines if they are causing you grief.. HTH --Geoff
Re: [Q] Apache::File-new
Ok, these are the lines from httpd.conf. The default-handler in /app/jsp
is inserted because I hope that i'll get resin taking over the request in
case the .pm declines. (hope this is right)
RewriteRule ^(.*)/(intl|de)/(.*) $1/jsp/$3 [QSA]
RewriteRule ^/$ /app/jap/home.jsp/23323.html [NS,R,L]
RewriteMap shortnames txt:/etc/apache/shortnames.txt
RewriteCond %{REQUEST_FILENAME} ^/[a-zA-Z0-9]+/?$
RewriteRule /([a-zA-Z0-9]+)/? ${shortnames:$1} [T=text/html,R,L,NS]
RewriteRule .*/favicon\.ico$ /statics/favicon.ico [PT]
RewriteRule ^/s\.gif$ /statics/pics/space.gif [PT]
RewriteRule ^/robots.txt$ /statics/robots.txt [NS,PT]
#pictures vom cms-server
RewriteRule ^/pictures/(.*) http://cms-dev/pictures/$1
# This one has to be the last in row:
RewriteRule ^(.*)_jsp(.*)$ $1.jsp$2 [QSA]
Location /app/jsp
SetHandler default-handler
/Location
# serve static files:
Location /app/jsp
SetHandler perl-script
PerlHandler Apache::StaticServer
/Location
Some lines from the .pm. Its purposeis to serve a static file instead of
the requested jsp. For instance, if I send a request for
something like "/app/jsp/category.jsp/23323" or "/app/jsp/category.jsp/23323.html"
the handler has to look after a file named
%{DOCUMENT_ROOT}/app/html/category_jsp/23323.html, and if it doesn't exist,
decline.
$catid = $r-path_info || "/23323"; # ancient rewrite rule
$fname = $r-filename;
$fname =~ s/.jsp$/_jsp/;
$fname =~ s:/jsp/:/html/:;
$fname .= $catid;
$fname .= ".html" unless $fname =~ /\.html$/; $r-log()-debug($fname."\n".$r-filename);
$fh = Apache::File-new($fname) || return DECLINED;
$r-header_out('Content-Length', -s $fname);
$r-update_mtime((stat $fname)[9]);
$r-send_http_header;
$r-send_fd($fh);
close $fh;
OK;
Here's a line from error_log which comes from the $r-log()-debug(...)
verse and says exactly what it has to:
[Tue Feb 12 15:03:55 2002] [debug] /usr/local/share/perl/5.6.1/ApacheStaticServer.pm(37):
[client 192.168.255.75] /home/disp05/app/html/category_jsp/67567.html
/home/disp05/app/jsp/category.jsp
If I send a request trhough a simple LWP client, here's what it says:
./client.pl http://disp05/app/jsp/category.jsp/67567
500 (Internal Server Error) unexpected EOF before status line seen
Client-Date: Tue, 12 Feb 2002 13:57:18 GMT
Ans this is what I find in my rewrite_log:
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(2) init rewrite engine with requested uri /app/jsp/category.jsp/67567
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '^(.*)/(intl|de)/(.*)' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '^/$' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '/([a-zA-Z0-9]+)/?' to uri '/app/jsp/category.jsp/67567'192.168.255.75
- - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(4) RewriteCond: input='/app/jsp/category.jsp/67567' pattern='^/[a-zA-Z0-9]+/?$'
= not-matched
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '.*/favicon\.ico$' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '^/s\.gif$' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '^/robots.txt$' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '^/pictures/(.*)' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(3) applying pattern '^(.*)_jsp(.*)$' to uri '/app/jsp/category.jsp/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b1154/initial]
(1) pass through /app/jsp/category.jsp/67567
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b5494/subreq]
(2) init rewrite engine with requested uri /67567
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b5494/subreq]
(3) applying pattern '^(.*)/(intl|de)/(.*)' to uri '/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b5494/subreq]
(3) applying pattern '.*/favicon\.ico$' to uri '/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b5494/subreq]
(3) applying pattern '^/s\.gif$' to uri '/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b5494/subreq]
(3) applying pattern '^/pictures/(.*)' to uri '/67567'
192.168.255.75 - - [12/Feb/2002:15:03:55 +0100] [disp05/sid#80aec3c][rid#81b5494/subreq]
(3) applying pattern '^(.*)_jsp(.*)$' to uri '/67567'
Re: Multiple authentication methods
Location /test AuthName Test AuthType Basic PerlSetVar myPDC SAMBA PerlSetVar myDOMAIN ARBEITSGRUPPE PerlAuthenHandler Apache::AuthenSmb Apache::AuthSybase require valid-user /Location is mod_perl compiled with STACKED HANDLERS? the first module to run will need to return DECLINED for the second to ever see the request. You may need a simple AuthHandler that always fails at the end. Try AuthenSmb, DECLINED or OK, try AuthSybase, DECLINED or OK, then AuthFailed, always returned FORBIDDEN. HTH, aaron -- aaron ross . alias intelligence, inc email . [EMAIL PROTECTED] phone . 215 545 6428
Question...
Hello all, I need to know how to clear the $ENV variables. For example, I use a .htaccess file for specific directories which requires the user to enter userID and password. When they exit the page, I want them to have to re-enter userID and passwd if they enter the page again. Does anyone know how this is accomplished? TIA, Ron
Re: [WOT] Google Programming Contest.
ABH == Ask Bjoern Hansen [EMAIL PROTECTED] writes: ABH The myth lives on. :-) It's not quite true. It was at UCLA and ABH the story was different: ABH http://nntp.perl.org/group/perl.advocacy;max=961 ABH http://nntp.perl.org/group/perl.advocacy/956 Quite lame to make a programming contest in which choice of language makes all problems easier. When we were running the Duke Internet Programming Contest (mid 90's) we allowed any and all languages for which we had a compiler. The last year we ran it, that even included Ada as provided by Sun, Haskell, and of course, perl, C, C++, Pascal, FORTRAN, shell script, and probably a few more. The folks that won usually picked the right language for the right problem. All of our working solutions given at the end of the contest were written in C. Naturally, the entire judging mechanism was written in perl (version 3 even!), except the submission programs, which were in /bin/sh for portability. Ahhh, the good ol' days. ;-) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: Question...
I need to know how to clear the $ENV variables. For example, I use a .htaccess file for specific directories which requires the user to enter userID and password. When they exit the page, I want them to have to re-enter userID and passwd if they enter the page again. Does anyone know how this is accomplished? Clearing %ENV will not work. You have to send a 403 response. Uwe
Re: [OT] Opera Cookies
RL == Robert Landrum [EMAIL PROTECTED] writes: RL I've recently come across some interesting behavior with Opera on linux. RL When I set a cookie using CGI::Cookie and Set-Cookie: headers, and RL then perform a JavaScript redirect to another page, the cookie IS NOT In my experience, the javascript in Opera is not quite up to snuff. I have many sites I go to that get javascript errors or warnings and massive malfunction. I'm pretty sure it is opera specific since they usually work ok with Konquerer (KDE browser). -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
RE: [Fwd: Samba authorization]
It seems that the problem does not reside with Smb.pm but with the shared object file Smb.so
RE: Multiple authentication methods
The get_handlers code is out of AuthenSmb as I do not have the slightest
idea of how to get the results of the called function.
Hmmm, It would seem that it would be better to call the function directly
from your handler. I am not sure how the AuthenSmb handlers should be
called but you should get the idea.
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
if ( Apache::AuthSybase-handler($r) == Apache::Constants::OK ) {
return Apache::Constants::OK;
} elsif ( Apache::AuthenSmb-handler($r) == Apache::Constants::OK ) {
return Apache::Constants::OK;
} else {
return Apache::Constant::DECLINED;
}
}
I get just as far, as I can authenticate via AuthSybase, but the second
method is never executed. Well, probably some expirienced perl coder would
laugh at me...
He he, we all had to start from the beginning ; )
Hmm, I fiddled a bit around whith this code but, it does not
really work the
way I want it to.
This is what I coded:
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
$r-push_handlers( PerlAuthenHandler= Apache::AuthSybase );
if (@{ $r-get_handlers(PerlAuthenHandler) || []}) {
return OK;
}
$r-push_handlers( PerlAuthenHandler= Apache::AuthenSmb );
if (@{ $r-get_handlers(PerlAuthenHandler) || []}) {
return OK;
}
return DECLINED;
}
The get_handlers code is out of AuthenSmb as I do not have the slightest
idea of how to get the results of the called function.
What the code should do is: Call AuthSybase, check return value, if OK
return OK, else call AuthenSMB, return return value.
Re: mod_perl + UNIVERSAL
* Despite numerous heroic efforts, HTTP HEAD requests are still screwed! Apache::Registry serves HEAD + Body, and Geoffrey's Apache::HEADRegistry doesn't work with redirects and 404's (I get like two headers and 3 bodies for 404's. Now that's verbose :-)) No real mod_perl problem on that - that's a problem (or maybe intentional functionality?) in Apache::Registry and Apache::HEADRegistry... actually, on this particular issue I think it is a design problem on mod_perl's part. if anyone is interested, he's my analysis... I think the problem here is that mod_perl sets the assbackward flag when setting headers via send_cgi_header() (which CGI.pm does). the assbackward flag means that Apache will forego sending headers itself. I think I understand Doug's logic in the code: send_cgi_header() prints the headers directly to the client, instead of setting $r-headers_out-set() and letting Apache do it, which is more like the way mod_cgi works. anyway, r-assbackward is a hack that mod_perl uses in a few places. the problem with messing with r-assbackward is that it really signifies an HTTP/0.9 response, for which GET is the only option, not HEAD. so... the normal Apache logic that cuts the body of the response out of a HEAD request (by checking r-header_only) is circumvented when r-assbackward is set. And, since Apache sends the body for REDIRECT and other errors (and not mod_perl) Apache doesn't know to _not_ send the body. get it? the routines in question are ap_send_error_response() in http_protocol.c and send_cgi_header() in Apache/Apache.pm (which calls mod_perl_sent_header() in mod_perl.c, which sets r-assbackward). I'm not sure if it is possible to easily work around this, but that's what I've come up with so far if anyone else wants to tackle this particular issue... --Geoff
AW: Multiple authentication methods
Thank you!
I also tried something like this at first. But I get this error message in
my apache/error.log
[Tue Feb 12 20:20:59 2002] [error] Can't locate object method handler via
package Apache::AuthenS
mb (perhaps you forgot to load Apache::AuthenSmb?) at
/usr/share/perl5/Apache/AuthenIntra.pm line
13.
resp. vice versa, when the AuthSybase method is first. Perhaps it is my
mod_perl installation. It is a stock Debian Woody installation.
Marcel
-Ursprüngliche Nachricht-
Von: Stathy G. Touloumis [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 12. Februar 2002 18:32
An: Marcel Weber; [EMAIL PROTECTED]
Betreff: RE: Multiple authentication methods
The get_handlers code is out of AuthenSmb as I do not have the slightest
idea of how to get the results of the called function.
Hmmm, It would seem that it would be better to call the function directly
from your handler. I am not sure how the AuthenSmb handlers should be
called but you should get the idea.
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
if ( Apache::AuthSybase-handler($r) == Apache::Constants::OK ) {
return Apache::Constants::OK;
} elsif ( Apache::AuthenSmb-handler($r) == Apache::Constants::OK ) {
return Apache::Constants::OK;
} else {
return Apache::Constant::DECLINED;
}
}
I get just as far, as I can authenticate via AuthSybase, but the second
method is never executed. Well, probably some expirienced perl coder would
laugh at me...
He he, we all had to start from the beginning ; )
Hmm, I fiddled a bit around whith this code but, it does not
really work the
way I want it to.
This is what I coded:
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
$r-push_handlers( PerlAuthenHandler= Apache::AuthSybase );
if (@{ $r-get_handlers(PerlAuthenHandler) || []}) {
return OK;
}
$r-push_handlers( PerlAuthenHandler= Apache::AuthenSmb );
if (@{ $r-get_handlers(PerlAuthenHandler) || []}) {
return OK;
}
return DECLINED;
}
The get_handlers code is out of AuthenSmb as I do not have the slightest
idea of how to get the results of the called function.
What the code should do is: Call AuthSybase, check return value, if OK
return OK, else call AuthenSMB, return return value.
RE: Multiple authentication methods
I also tried something like this at first. But I get this error message in
my apache/error.log
[Tue Feb 12 20:20:59 2002] [error] Can't locate object method
handler via
package Apache::AuthenS
mb (perhaps you forgot to load Apache::AuthenSmb?) at
/usr/share/perl5/Apache/AuthenIntra.pm line
13.
Try calling it via Apache::AuthenSmb::handler($r) instead. You will
probably want to do the same with Apache::AuthSybase::handler($r) as well.
resp. vice versa, when the AuthSybase method is first. Perhaps it is my
mod_perl installation. It is a stock Debian Woody installation.
Marcel
-Ursprüngliche Nachricht-
Von: Stathy G. Touloumis [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 12. Februar 2002 18:32
An: Marcel Weber; [EMAIL PROTECTED]
Betreff: RE: Multiple authentication methods
The get_handlers code is out of AuthenSmb as I do not have the slightest
idea of how to get the results of the called function.
Hmmm, It would seem that it would be better to call the function directly
from your handler. I am not sure how the AuthenSmb handlers should be
called but you should get the idea.
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
if ( Apache::AuthSybase-handler($r) == Apache::Constants::OK ) {
return Apache::Constants::OK;
} elsif ( Apache::AuthenSmb-handler($r) == Apache::Constants::OK ) {
return Apache::Constants::OK;
} else {
return Apache::Constant::DECLINED;
}
}
I get just as far, as I can authenticate via AuthSybase, but the second
method is never executed. Well, probably some expirienced perl
coder would
laugh at me...
He he, we all had to start from the beginning ; )
Hmm, I fiddled a bit around whith this code but, it does not
really work the
way I want it to.
This is what I coded:
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
$r-push_handlers( PerlAuthenHandler= Apache::AuthSybase );
if (@{ $r-get_handlers(PerlAuthenHandler) || []}) {
return OK;
}
$r-push_handlers( PerlAuthenHandler= Apache::AuthenSmb );
if (@{ $r-get_handlers(PerlAuthenHandler) || []}) {
return OK;
}
return DECLINED;
}
The get_handlers code is out of AuthenSmb as I do not have the slightest
idea of how to get the results of the called function.
What the code should do is: Call AuthSybase, check return value, if OK
return OK, else call AuthenSMB, return return value.
Re: Genius for hire
Hi there, On 11 Feb 2002, jon schatz wrote: Can I request then that the suggested tag [JOB] be used for such postings? Please see http://perl.apache.org/email-etiquette.html 73, Ged.
POST without any content - sometimes
Hi! I have a board script to which users can post (of course) One IP-address has sometimes problems posting to that script, though. Look at the log's below. xxx.xxx.25.50 - - [10/Feb/2002:21:15:33 +0100] POST /cgi-bin/mboard/message.pl HTTP/1.1 200 88 - Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) xxx.xxx.25.50 - - [10/Feb/2002:21:15:36 +0100] POST /cgi-bin/mboard/message.pl HTTP/1.1 200 1683 http://www.servern.nu/main.html; Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) The first POST is erronuos as there is no content (-) and the script won't accept it as vaild. The scond POST is okay as it has content (http://www.servern.nu/main.html;). This happens ONLY to that IP-address. Since I havn't been able to find anything to do about the problem, and since it seems to come and go, and since it is only that IP-address, i draw the conclusion that the problem really isn't mine, but what causes it??? How can the POST loose it's content like that? I know who the user is so I know it's an actual post that he tried to make. The IP-address is an alias to a whole net with NAT (Linux). Could it be some kind of proxy-web-cache or something that causes the problem? Please excuse my poor english... Best Regards Anders, admin servern.nu
Re: About PerlLogHandler phase
Hi there, On Tue, 12 Feb 2002, James G Smith wrote: Randy J. Ray [EMAIL PROTECTED] wrote: * Are there ways to register other log types, in addition to the access, error, etc.? Such that people could specify those (and a format) the same way they specify the others? More to the point, so that there might be a ready file-descriptor I could print to, rather than having to deal with the open/lock/write/unlock/close cycle. You can pipe all logs to your own scripts/executables/whatever and do what you like with them, or use syslog if you're on *x and into that kind of pain. It's in the doc's. 73, Ged.
Re: Influencing @INC list
Hi there, On Mon, 11 Feb 2002, Kevin Slean wrote: I need to run multiple apache servers on one Solaris 2.7 box configured in such a way that each of them accesses their own private copy of perl libraries. Could you accept recompiling Perl without the couple of paths which get in the way, and then add the missing paths with use lib(...)? There's lots of stuff about @INC in the Guide. 73, Ged.
Re: POST without any content - sometimes
Hi there, On Tue, 12 Feb 2002, Anders Knuts wrote: I have a board script to which users can post (of course) One IP-address has sometimes problems posting to that script, though. [snip] really isn't mine, but what causes it??? How can the POST loose it's content like that? [snip] Could it be some kind of proxy-web-cache or something that causes the problem? No idea. Sounds like a lot of fun though. Time to dig out tcpdump? Please excuse my poor english... It's fine. 73, Ged.
AW: Multiple authentication methods
Hi
This way, I do not get any failure messages, but the authenication does not
work at all. Say, it does not matter wat password your typing in, you get
always authenticated. Even when one auf the handlers logs a violation and
return AUTH_REQUIRED / DECLINED.
package Apache::AuthenIntra;
use strict;
use Apache::AuthenSmb;
use Apache::AuthSybase;
use Apache::Constants;
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
if ( Apache::AuthenSmb::handler($r) == Apache::Constants::OK ) {
return Apache::Constants::OK;
} elsif ( Apache::AuthSybase::handler($r) == Apache::Constants::OK )
{
return Apache::Constants::OK;
}
$r-note_basic_auth_failure;
return Apache::Constant::AUTH_REQUIRED;
}
Marcel
-Ursprüngliche Nachricht-
Von: Stathy G. Touloumis [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 12. Februar 2002 18:32
An: Marcel Weber; [EMAIL PROTECTED]
Betreff: RE: Multiple authentication methods
The get_handlers code is out of AuthenSmb as I do not have the slightest
idea of how to get the results of the called function.
Hmmm, It would seem that it would be better to call the function directly
from your handler. I am not sure how the AuthenSmb handlers should be
called but you should get the idea.
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
if ( Apache::AuthSybase-handler($r) == Apache::Constants::OK ) {
return Apache::Constants::OK;
} elsif ( Apache::AuthenSmb-handler($r) == Apache::Constants::OK ) {
return Apache::Constants::OK;
} else {
return Apache::Constant::DECLINED;
}
}
I get just as far, as I can authenticate via AuthSybase, but the second
method is never executed. Well, probably some expirienced perl coder would
laugh at me...
He he, we all had to start from the beginning ; )
Hmm, I fiddled a bit around whith this code but, it does not
really work the
way I want it to.
This is what I coded:
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
$r-push_handlers( PerlAuthenHandler= Apache::AuthSybase );
if (@{ $r-get_handlers(PerlAuthenHandler) || []}) {
return OK;
}
$r-push_handlers( PerlAuthenHandler= Apache::AuthenSmb );
if (@{ $r-get_handlers(PerlAuthenHandler) || []}) {
return OK;
}
return DECLINED;
}
The get_handlers code is out of AuthenSmb as I do not have the slightest
idea of how to get the results of the called function.
What the code should do is: Call AuthSybase, check return value, if OK
return OK, else call AuthenSMB, return return value.
Re: mod_perl + UNIVERSAL
I think the problem here is that mod_perl sets the assbackward flag when setting headers via send_cgi_header() (which CGI.pm does). Is this only an issue when using CGI.pm or PerlSendHeader then? I seem to recall having no trouble doing this from a normal handler. - Perrin
RE: Multiple authentication methods
That is odd, I would check the interface for the authentication modules and
be sure that they are being used properly. It may help to also put in some
debug/trace statements to figure out where things are failing or not working
as expected : )
This way, I do not get any failure messages, but the
authenication does not
work at all. Say, it does not matter wat password your typing in, you get
always authenticated. Even when one auf the handlers logs a violation and
return AUTH_REQUIRED / DECLINED.
package Apache::AuthenIntra;
use strict;
use Apache::AuthenSmb;
use Apache::AuthSybase;
use Apache::Constants;
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
if ( Apache::AuthenSmb::handler($r) == Apache::Constants::OK ) {
return Apache::Constants::OK;
} elsif ( Apache::AuthSybase::handler($r) ==
Apache::Constants::OK )
{
return Apache::Constants::OK;
}
$r-note_basic_auth_failure;
return Apache::Constant::AUTH_REQUIRED;
}
Marcel
-Ursprüngliche Nachricht-
Von: Stathy G. Touloumis [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 12. Februar 2002 18:32
An: Marcel Weber; [EMAIL PROTECTED]
Betreff: RE: Multiple authentication methods
The get_handlers code is out of AuthenSmb as I do not have the slightest
idea of how to get the results of the called function.
Hmmm, It would seem that it would be better to call the function directly
from your handler. I am not sure how the AuthenSmb handlers should be
called but you should get the idea.
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
if ( Apache::AuthSybase-handler($r) == Apache::Constants::OK ) {
return Apache::Constants::OK;
} elsif ( Apache::AuthenSmb-handler($r) == Apache::Constants::OK ) {
return Apache::Constants::OK;
} else {
return Apache::Constant::DECLINED;
}
}
I get just as far, as I can authenticate via AuthSybase, but the second
method is never executed. Well, probably some expirienced perl
coder would
laugh at me...
He he, we all had to start from the beginning ; )
Hmm, I fiddled a bit around whith this code but, it does not
really work the
way I want it to.
This is what I coded:
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
$r-push_handlers( PerlAuthenHandler= Apache::AuthSybase );
if (@{ $r-get_handlers(PerlAuthenHandler) || []}) {
return OK;
}
$r-push_handlers( PerlAuthenHandler= Apache::AuthenSmb );
if (@{ $r-get_handlers(PerlAuthenHandler) || []}) {
return OK;
}
return DECLINED;
}
The get_handlers code is out of AuthenSmb as I do not have the slightest
idea of how to get the results of the called function.
What the code should do is: Call AuthSybase, check return value, if OK
return OK, else call AuthenSMB, return return value.
Re: Question...
Cookies! /me is in smartass mode today. --Jon Ron Beck wrote: Hello all, I need to know how to clear the $ENV variables. For example, I use a .htaccess file for specific directories which requires the user to enter userID and password. When they exit the page, I want them to have to re-enter userID and passwd if they enter the page again. Does anyone know how this is accomplished? TIA, Ron
Re: mod_perl + UNIVERSAL
Perrin Harkins wrote: I think the problem here is that mod_perl sets the assbackward flag when setting headers via send_cgi_header() (which CGI.pm does). Is this only an issue when using CGI.pm or PerlSendHeader then? I seem to recall having no trouble doing this from a normal handler. yeah, from what I can tell, CGI.pm is the only issue with HEADRegistry.pm. print Location: foo seems to work fine. I don't think PerlSendHeader is the problem - I tried it both ways IIRC. Apache::Registry doesn't handle HEAD requests at all, I don't think - HEADRegistry.pm respects $r-header_only and runs into this problem with redirects, Registry doesn't even try. for normal mod_perl handlers it shouldn't be an issue - it's up to the handler to check $r-header_only and take appropriate action, which is typically setting headers using $r-headers_out and returning an appropriate value. after a while, my mind started swimming in circles and I gave up :) --Geoff
Re: mod_perl + UNIVERSAL
However both applications make use of the UNIERVSAL package to create universally accessible methods (to return the current database handle for example) within the application. Better to put those into a package of your own and call them with fully-qualified names, or import them as Tatsuhiko demonstrated. The thing is I am getting some weird behaviour where one application seems to be getting code from the other. In theory this isn't possible with the separated namespaces. I suspect my UNIERVSAL use is the problem. There is just one Perl interpreter per process, and thus one namespace and one UNIVERSAL package. If you try to create two different versions of the sub UNIVERSAL::foo() it won't work: there can be only one. This is true for any package name, actually. If you need separate subs, name them differently or put them in separate packagaes. - Perrin
Re: mod_perl + UNIVERSAL
A list of things I've noticed: * If you have two *different* modules which have the same name, then either one, or the other is loaded in memory, never both. This is dead annoying. I think Perl standard modules + CPAN modules should be shared, other modules which are specific to a given script should not. This is how perl works. You are not allowed to have two different modules with the same name loaded in the same interpreter. If you can't deal with that, maybe you should consider using an environment like Mason or Embperl which allow a page-based approach closer to PHP, rather than using perl's package namespace. It is also true that mod_perl 2 will have additional support for doing fancy things with virtual hosts, like having separate pools of interpreters (and thus separate namespaces) for each virtual host. See http://perl.apache.org/~dougm/modperl_2.0.html for more. I am not the only developer on the planet. For instance there is a CPAN module called HTML::Tree. But there is also another module on the web called HTML_Tree, which installs itself as HTML::Tree. One person's mistake hardly justifies a massive change in the way namespaces work in perl. Anyway, that was fixed, thanks to Terrence Brannon. His HTML::Seamstress module replaces the former HTML_Tree. * Global variables should be reinitialized on each request. Or at least if we want them to be persistent we do not want them to be shared with different scripts on different virtual hosts! Global variables are variables without scope. They are not cleaned up by definition. If you want variables that go out of scope, use lexicals. If you have legacy code that depends on mod_cgi behavior to work, use Apache::PerlRun which clears globals on each request. * Perl garbage collector should be smarter (okay, that may not be a mod_perl issue). C geeks out there, ain't it possible to compile a version of Perl with a better GC? Doug has talked about doing something with this in mod_perl 2 to help clean up memory taken for lexicals, but it's not definite. And yes, this is really a Perl issue, not a mod_perl one. - Perrin
AW: Multiple authentication methods
It works
I don't get the point why it did not work the other way round, but now
everything is just fine now :
package Apache::AuthenIntra;
#use strict;
use Apache::AuthenSmb;
use Apache::AuthSybase;
use Apache::Constants;
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
if ( Apache::AuthenSmb::handler($r) == OK ) {
$r-log_reason(AuthenSmb is okay, $r-uri);
return OK;
} elsif ( Apache::AuthSybase::handler($r) == OK ) {
$r-log_reason(AuthSybase is okay, $r-uri);
return OK;
}
$r-note_basic_auth_failure;
return AUTH_REQUIRED;
}
1;
__END__
Like this, you may take every authentication module you'd like, wether it
returns DECLINE or AUTH_REQUIRED and it will give an OK if one of the two
works.
Thanks to all who helped me
Marcel
-Ursprüngliche Nachricht-
Von: Stathy G. Touloumis [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 12. Februar 2002 21:17
An: Marcel Weber; [EMAIL PROTECTED]
Betreff: RE: Multiple authentication methods
That is odd, I would check the interface for the authentication modules and
be sure that they are being used properly. It may help to also put in some
debug/trace statements to figure out where things are failing or not working
as expected : )
This way, I do not get any failure messages, but the
authenication does not
work at all. Say, it does not matter wat password your typing in, you get
always authenticated. Even when one auf the handlers logs a violation and
return AUTH_REQUIRED / DECLINED.
package Apache::AuthenIntra;
use strict;
use Apache::AuthenSmb;
use Apache::AuthSybase;
use Apache::Constants;
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
if ( Apache::AuthenSmb::handler($r) == Apache::Constants::OK ) {
return Apache::Constants::OK;
} elsif ( Apache::AuthSybase::handler($r) ==
Apache::Constants::OK )
{
return Apache::Constants::OK;
}
$r-note_basic_auth_failure;
return Apache::Constant::AUTH_REQUIRED;
}
Marcel
-Ursprüngliche Nachricht-
Von: Stathy G. Touloumis [mailto:[EMAIL PROTECTED]]
Gesendet: Dienstag, 12. Februar 2002 18:32
An: Marcel Weber; [EMAIL PROTECTED]
Betreff: RE: Multiple authentication methods
The get_handlers code is out of AuthenSmb as I do not have the slightest
idea of how to get the results of the called function.
Hmmm, It would seem that it would be better to call the function directly
from your handler. I am not sure how the AuthenSmb handlers should be
called but you should get the idea.
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
if ( Apache::AuthSybase-handler($r) == Apache::Constants::OK ) {
return Apache::Constants::OK;
} elsif ( Apache::AuthenSmb-handler($r) == Apache::Constants::OK ) {
return Apache::Constants::OK;
} else {
return Apache::Constant::DECLINED;
}
}
I get just as far, as I can authenticate via AuthSybase, but the second
method is never executed. Well, probably some expirienced perl
coder would
laugh at me...
He he, we all had to start from the beginning ; )
Hmm, I fiddled a bit around whith this code but, it does not
really work the
way I want it to.
This is what I coded:
sub handler {
my $r = shift;
my($res, $sent_pw) = $r-get_basic_auth_pw;
return $res if $res != OK;
$r-push_handlers( PerlAuthenHandler= Apache::AuthSybase );
if (@{ $r-get_handlers(PerlAuthenHandler) || []}) {
return OK;
}
$r-push_handlers( PerlAuthenHandler= Apache::AuthenSmb );
if (@{ $r-get_handlers(PerlAuthenHandler) || []}) {
return OK;
}
return DECLINED;
}
The get_handlers code is out of AuthenSmb as I do not have the slightest
idea of how to get the results of the called function.
What the code should do is: Call AuthSybase, check return value, if OK
return OK, else call AuthenSMB, return return value.
RE: mod_perl + UNIVERSAL
* Global variables should be reinitialized on each request. Or at least if we want them to be persistent we do not want them to be shared with different scripts on different virtual hosts! Try looking into the way mod_perl hooks into the apache configuration. This may work for setting site wide constants globals depending on how you use them. You can then set different values for virtual hosts or even allow directives to be set in '.htaccess' files. * Perl garbage collector should be smarter (okay, that may not be a mod_perl issue). C geeks out there, ain't it possible to compile a version of Perl with a better GC? There really is no reason to cleanup the globals since they are still referenced and in memory. Perhaps you can consider an interface around your code which can handle the cleanup and such of any variables. You could also set a 'cleanup' handler to 'unload' the module from the process when it is completed or even 'undef' specific variables. That way you can clear out the namespace and then other scripts calling the same named module but from a different path can actually load it.
Authentication???
I am trying decide which authentication scheme to use with Apache on Solaris. I want to be able to issue cookies and expire them after a set duration. What is the best method/module(s)? And which provides the most documentation on setup and configuration? Thanks, --Ray
RE: mod_perl + UNIVERSAL
This is what I thought but I am not getting behaviour that indicates this.
To explain.
I have two applications, a forums program and a basic portal. Both of these
run on the same server under virtual servers. Both .pl's have a section
where they switch into the UNIVERSAL package and setup some global routines.
For example:
in forums.pl
sub main {
# init type stuff
}
sub loader {
}
package UNIVERSAL;
sub print_error {
# Global error logging routine
}
The portal.pl has the equivalent. The problem I am getting is that under
some as of yet unknown circumstances the print_error from portal is coming
up in forums. But, and here's the bit that's confusing me, under normal
operating they seem to coexist fine. forums.pl gets it's print_error (i.e.
somewhere is calling $self-print_error) and portal.pl get's it's. How is it
possible for this to happen at all? If the UNIVERSAL namespace is shared I
would have thought one or the other (the last one?) would get the
print_error sub and the other loses out but at some point they seem to
coexist just fine. Whilst at some other point they as expected and one gets
the others. Any theories?
Matt.
-Original Message-
From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 13 February 2002 7:45 AM
To: Morton-Allen, Matthew; [EMAIL PROTECTED]
Subject: Re: mod_perl + UNIVERSAL
However both applications make use of the UNIERVSAL package to create
universally accessible methods (to return the current database handle for
example) within the application.
Better to put those into a package of your own and call them with
fully-qualified names, or import them as Tatsuhiko demonstrated.
The thing is I am getting some weird behaviour where one application seems
to be getting code from the other. In theory this isn't possible with the
separated namespaces. I suspect my UNIERVSAL use is the problem.
There is just one Perl interpreter per process, and thus one namespace and
one UNIVERSAL package. If you try to create two different versions of the
sub UNIVERSAL::foo() it won't work: there can be only one. This is true for
any package name, actually. If you need separate subs, name them
differently or put them in separate packagaes.
- Perrin
Re: Authentication???
Have you looked at Apache::AuthCookie? Ray Recendez wrote: 002101c1b40c$fa6ab930$d4fe97c6@RAYWIN"> I am trying decide which authentication scheme to use with Apache on Solaris. I want to be able to issue cookies and expire them after a set duration. What is the best method/module(s)? And which provides the most documentation on setup and configuration? Thanks, --Ray
RE: mod_perl + UNIVERSAL
Hi all, On Tue, 12 Feb 2002, Stathy G. Touloumis wrote: There really is no reason to cleanup the globals since they are still referenced and in memory. Perhaps you can consider an interface around your code which can handle the cleanup and such of any variables. You could also set a 'cleanup' handler to 'unload' the module from the process when it is completed or even 'undef' specific variables. That way you can clear out the namespace and then other scripts calling the same named module but from a different path can actually load it. Of course all of this tends to go in the opposite direction from that in which mod_perl tries to go: the idea is to do as little processing as possible (particularly things like compiling modules) for each request. 73, Ged.
Re: mod_perl + UNIVERSAL
If the UNIVERSAL namespace is shared I would have thought one or the other (the last one?) would get the print_error sub and the other loses out but at some point they seem to coexist just fine. Whilst at some other point they as expected and one gets the others. Any theories? You have a bunch of different processes running. Some of them hit the forums first, and some hit the portal first. Last one wins. - Perrin
RE: mod_perl + UNIVERSAL
: ) As with any application that depends on the requirements. There really is no reason to cleanup the globals since they are still referenced and in memory. Perhaps you can consider an interface around your code which can handle the cleanup and such of any variables. You could also set a 'cleanup' handler to 'unload' the module from the process when it is completed or even 'undef' specific variables. That way you can clear out the namespace and then other scripts calling the same named module but from a different path can actually load it. Of course all of this tends to go in the opposite direction from that in which mod_perl tries to go: the idea is to do as little processing as possible (particularly things like compiling modules) for each request.
Re: Apache::DBI
I had tried that, with the same result. (does
Apache::DBI overload the DBI methods?) Full
error is as follows. Again, any help is _highly_
appreciated.
Marty
[error] Can't locate object method connect_on_init via package Apache::DBI at
/etc/httpd/conf/startup.pl line 28.
Compilation failed in require at (eval 14) line 1.
Syntax error on line 1276 of /usr/local/apache/conf/httpd.conf:
Can't locate object method connect_on_init via package Apache::DBI at
/etc/httpd/conf/startup.pl line 28.
Compilation failed in require at (eval 14) line 1.
--
On Tue, 12 Feb 2002 08:44:12 Martin Haase-Thomas wrote:
Marty J. Rogers wrote:
[snip]
From httpd.conf:
PerlModule Apache::DBI CGI DBD::mysql \
Apache::AuthenDBI
PerlRequire /path/to/startup.pl
Alias /perl/ /path/to/perl
PerlModule Apache::Registry
Location /perl
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all
PerlSendHeader On
/Location
and from startup.pl:
use DBI();
use Apache::DBI(); # !! :)
use DBD::mysql();
.
.
.
DBI-connect_on_init(DBI:mysql:dbname,
user,pass,
{Options here}
Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at
http://www.eudoramail.com
Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at
http://www.eudoramail.com
Re: [Fwd: Samba authorization]
Stathy G. Touloumis wrote: It seems that the problem does not reside with Smb.pm but with the shared object file Smb.so I reinstalled Authen-Smb, - Smb.so looks good :) and is there where it must be. What may be wrong with this file? -- Andrew
Re: Apache::DBI
(doesApache::DBI overload the DBI methods?)
No, it doesn't. It uses Apache and DBI. Did you install the package via the
"Makefile.PL" stanza? Maybe you should just install it another time. On the
other hand, Apache::DBI doesn't export anything. Try calling it with the
package name explicitly.
kind regards
Martin
Marty J. Rogers wrote:
[EMAIL PROTECTED]">
I had tried that, with the same result. (doesApache::DBI overload the DBI methods?) Fullerror is as follows. Again, any help is _highly_appreciated.Marty[error] Can't locate object method "connect_on_init" via package "Apache::DBI" at /etc/httpd/conf/startup.pl line 28.Compilation failed in require at (eval 14) line 1.Syntax error on line 1276 of /usr/local/apache/conf/httpd.conf:Can't locate object method "connect_on_init" via package "Apache::DBI" at /etc/httpd/conf/startup.pl line 28.Compilation failed in require at (eval 14) line 1.--On Tue, 12 Feb 2002 08:44:12 Martin Haase-Thomas wrote:
Marty J. Rogers wrote:
[snip]From httpd.conf:PerlModule Apache::DBI CGI DBD::mysql \Apache::AuthenDBIPerlRequire /path/to/startup.plAlias /perl/ /path/to/perlPerlModule Apache::RegistryLocation /perlSetHandler perl-scriptPerlHandler Apache::RegistryOptions ExecCGIallow from allPerlSendHeader On/Locationand from startup.pl:use DBI();
use Apache::DBI(); # !! :)
use DBD::mysql();...DBI-connect_on_init("DBI:mysql:dbname", "user","pass", {Options here}Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com
Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com
