Re: PerlAuthenHandler advice needed.
Here's a simple handler that will set the AuthType and AuthName
dynamically and handle the authentication for you. This handler will
prompt you for a password when you try to acess /manual with the
AuthName, "The Manual" and prompt with the AuthName "The Icons" when you
try to access /icons. These urls are part of Apaches basic installation
(that's if you did not remove the manual from your htdocs directory).
The authentication phase will let you in just as long you supply a
username and password. You can of course code such that it you can
authenicate against a .htpassword file, using Apache::Htpasswd.
Anyhow, this should show you that you can indeed change the AuthName
on-the-fly and also handle
authentication without having to include AuthName,AuthType,AuthUserFile
explicitly in your httpd.conf.
Note: the authentication subroutine acted flaky, sometimes it worked and
other times it didn't. But the realms did change for the each uri.
i hope this helps youhave fun ;)
Setting it up:
In your httpd.conf ( in a global area):
PerlHeaderParserHandler Apache::SetRealm;
=code
package Apache::SetRealm;
use Apache;
use Apache::Constants qw(:common);
sub handler {
my $r = shift;
## Make Apache aware the we want to also handle the Authentication
phase using a custom
## handler, in this case the subroutine authenticate()
$r->push_handlers(PerlAuthenHandler => \&authenticate);
my $uri = $r->uri;
## only handle uri that are defined as protected, in this case the
only protected
## uri's are /icons and /manuals
return OK unless is_protected($r);
my $realm = get_realm($r);
## Construct the Header Field containing the type of authenticate
(Basic) and our
## realmname return by get_realm()
my $authheader = 'Basic realm="'.$realm.'"';
$r->header_out("WWW-Authenticate" ,$authheader);
## Return 401 to browser and prompt for login
$r->status(AUTH_REQUIRED);
$r->send_http_header("text/html");
return AUTH_REQUIRED;
}
sub get_realm {
## Get the AuthName for a specific uri. You can probably read these
off of a file that
## contains a list of uri's and realmNames
my $r = shift;
return "The Icons" if ($r->uri =~ /\/icons/);
return "The Manual" if ($r->uri =~ /\/manual/);
}
sub is_protected {
## Check the $uri requested matches our set of "Restricted"
locations
## 1 = isProtected, 0 = NotProtected
## You can probably have these protected areas in a seperate file,
the eagle book
## has some excellent ideas on how to acomplish this
my $r = shift;
my @protected = ('\/manual','\/icons');
for (@protected) { return 1 if ($r->uri =~ /$_/); }
return 0;
}
sub authenticate {
## Straight out of the Eagle Book
my $r = shift;
return OK if $r->sub_request;
my ($res,$password) = $r->get_basic_auth_pw;
return $res if $res != OK;
my $username = $r->connection->user;
unless ($username && $pass) {
$r->note_basic_auth_failure;
$r->log_reason("Did not provide username");
return AUTH_REQUIRED;
}
## Now that you have the $username and $password you can
## include your code to open your AuthUserFile to check the password
and username
## I suggest using Apache::Htpasswd, it provides all the
methods/functions that you need to
## accomplish this part of the task...
$r->log_reason("WELCOME $user");
return OK;
}
1;
-Carlos
Todd Chapman wrote:
>
> Please explain again how to get my AuthHandler called without setting
> AuthName or AuthType in httpd.conf.
>
> Thanks.
>
> -Todd
>
> On Wed, 27 Sep 2000, Carlos Ramirez wrote:
>
> > By choosing to use your custom AuthHandler, you basically override Apache's way of
> > handling the particular phase, in this case the authentication phase. So you must
> > handle prompting the user and also checking the password.
> >
> > You might want to read the Apache Guide (http://perl.apache.org/) on how to write
>you
> > own handler and also the eagle book.
> >
> > After reviewing our previous conversation, I think you might need to send
> > WWW-Authenticate header field in another phase (preferable at the
> > PerlHeaderParserHandler) before the Authentication phase is called.
> >
> > Your PerlHeaderParserHandler can check the $r->uri for any password protected
> > requests, i.e., if it matches /companyA, you can then set the WWW-Authenticate:
>Basic
> > $realm and push it along it's merry way.
> >
> > Then your PerlAuthHandler will get the username and password and check it against
>the
> > realms' AuthUserFile. Apache will handle the initial prompting for the
> > username/password.
> >
> > Your requirements imply that you will have a file(??) that has a list of UserFiles
> > for each Realm/path_info so that your authentication handler will know what file to
> > check against.
> >
> > I hope this make sense ;) my coffee is running low...
> >
> > -Carlos
Re: Apache::ASP error
Souds like you need to include the library where ASP.pm is located in your PATH. Shold be something like G:\Program Files\Apache Group\Perl\site\5.6.0\lib\Apache Rod - Original Message - From: "Phong Le Quoc" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 27, 2000 7:52 PM Subject: Apache::ASP error > I installed Apache::ASP. When test with a simple asp > page. I got an internal server error and the error_log > says: > > [Wed Sep 27 02:11:07 2000] [error] Can't locate > Apache/ASP.pm in @INC (@INC contains: G:/Program > Files/Apache Group/Perl/5.6.0/lib/MSWin32-x86 > G:/Program Files/Apache Group/Perl/5.6.0/lib > G:/Program Files/Apache > Group/Perl/site/5.6.0/lib/MSWin32-x86 G:/Program > Files/Apache Group/Perl/site/5.6.0/lib . /apache/ > /apache/lib/perl) at (eval 4) line 3. > > [Wed Sep 27 02:11:07 2000] [error] Undefined > subroutine &Apache::ASP::handler called. > > > Thanks. > > __ > Do You Yahoo!? > Send instant messages & get email alerts with Yahoo! Messenger. > http://im.yahoo.com/ >
Re: PerlAuthenHandler advice needed.
Please explain again how to get my AuthHandler called without setting AuthName or AuthType in httpd.conf. Thanks. -Todd On Wed, 27 Sep 2000, Carlos Ramirez wrote: > By choosing to use your custom AuthHandler, you basically override Apache's way of > handling the particular phase, in this case the authentication phase. So you must > handle prompting the user and also checking the password. > > You might want to read the Apache Guide (http://perl.apache.org/) on how to write you > own handler and also the eagle book. > > After reviewing our previous conversation, I think you might need to send > WWW-Authenticate header field in another phase (preferable at the > PerlHeaderParserHandler) before the Authentication phase is called. > > Your PerlHeaderParserHandler can check the $r->uri for any password protected > requests, i.e., if it matches /companyA, you can then set the WWW-Authenticate: Basic > $realm and push it along it's merry way. > > Then your PerlAuthHandler will get the username and password and check it against the > realms' AuthUserFile. Apache will handle the initial prompting for the > username/password. > > Your requirements imply that you will have a file(??) that has a list of UserFiles > for each Realm/path_info so that your authentication handler will know what file to > check against. > > I hope this make sense ;) my coffee is running low... > > -Carlos > > > Todd Chapman wrote: > > > Thanks for the help. I was hoping that Apache would check the password for > > me but this should work. > > > > Now, how do I get Apache to run my PerlAuthenHandler without setting the > > AuthType or AuthName in httpd.conf? > > > > Do I need to do the Authentication in a PerlHandler? > > > > -Todd > > > > On Wed, 27 Sep 2000, Carlos Ramirez wrote: > > > > > 1. Oh, I mis-interpreted your question. I thought you already had a list of > > > virtual directories with the > > > AuthNames defined. > > > > > > You can set the AuthName by sending them in the server response header field: > > > > > > WWW-Authenticate Basic $realm > > > > > > So the first request to /companyA, you AuthHandler will respond with: > > > > > > $r->header_out(WWW-Authenticate => 'Basic $realm); ## Sets Realm field > > > $r->note_basic_auth_failure; ## Prompts for password > > > > > > The when a username and password are supplied i.e. > > > ($ret,$password) = $r->get_basic_auth_pw; > > > > > > where $ret = 1; > > > > > > Then: > > > 1. determine the AuthUserFile > > > 2. use Apache::Htpasswd to check password > > > > > > -Carlos > > > > > > > > > > > > > > > > > > > > > > > > Todd Chapman wrote: > > > > > > > Problems with your suggestion: > > > > > > > > 1. The realm will not be known until I get path_info so > > > > directives will not work. > > > > > > > > 2. How can I get Perl to do the password lookup in the dynamically > > > > selected AuthUserFile? > > > > > > > > Thanks for the help. > > > > > > > > -Todd > > > > > > > > On Wed, 27 Sep 2000, Carlos Ramirez wrote: > > > > > > > > > You can you use Location to specify seperate AuthUserFile's like so: > > > > > > > > > > > > > > > AuthType Basic > > > > > AuthName CompanyA > > > > > AuthUserFile path/to/CompanyAUsersFile > > > > > > > > > > > > > > > > > > > > > > > > > AuthType Basic > > > > > AuthName CompanyN > > > > > AuthUserFile path/to/CompanyNUsersFIle > > > > > > > > > > > > > > > > > > > > Or you can write your own AuthHandler that lookups up AuthName, AuthUserFile > > > > > in a seperate file against the path_info. This will eliminate the need to > > > > > flood you httpd.conf file with a bunch of directives. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Todd Chapman wrote: > > > > > > > > > > > I have read chapter 6 of the modperl book but still don't know how to set > > > > > > up authenification the way I want. I would like to use Basic > > > > > > authentification to protect virtual documents. The trick is that I want > > > > > > to set AuthName and AuthUserFile based on path_info. > > > > > > > > > > > > For example: > > > > > > > > > > > > http://virtual/companyA/dir1 > > > > > > > > > > > > would prompt for a password in the companyA realm and check it against the > > > > > > appropriate AuthUserFile. > > > > > > > > > > > > How do I add this flexibility without reinventing the parts Apache already > > > > > > does so well? > > > > > > > > > > > > Thanks. > > > > > > > > > > > > -Todd > > > > > > > > > > -- > > > > > --- > > > > > Carlos Ramirez + Boeing + Reusable Space Systems + 714.372.4181 > > > > > --- > > > > > - Someday I'll find that peer and reset his connection! > > > > > > > > > > > > > > > > > > > > > -- > > > --- > > > Carlos Ramirez + Boeing + Reusable Space Systems + 714.372.4181 > > > --
suggestions needed re. required files and persistent data
Hi Guys I am in serious diffs here attempting to port a legacy system. We use a custom tag system with template pages and a custom parser. This has been working for several years in a modd_cgi environment, but due to performance problems is being ported to mod_perl. The parser has been ported and works fine, as do most of the libraries. The problem I am facing is with our database definition files. These are custom files which are required at run time. The file consists of a long series of subroutine calls with arguments that refer to the definitions of fields, tables, etc. They are used in conjunction with a series of internal libraries to provide information for displaying data, handling file upload locations, etc. The subroutines modify data in global variables. The subroutines called exist in the calling module's namespace. When used as supplied they caused a significant memory leak (~120K per request). I have done a lot of work over the past few days to try and deal with the system to make it function as expected, but with no success. It would be nice if this data could be read and compiled at server start. I experimented with IPC::Shareable, but when I attempted to do anything with it in my startup.pl file it segfaulted the server and httpd would not start. I have got myself to a situation where I can get the data in to memory and work with it for some requests. With three child processes running we get a situation where the data will load for the first three requests, then the next three will not have the data, then one will segfault, then no data then data appears again. I am slowly going mad with this. I can get things working without all of this nonsense and just using DBI, but word from above says that this must be integrated. I know there is not much to go on in this email, but if anyone wants to help, respond by email and I can give you more information. -- John Reid Senior Analyst/Programmer Open Connect (Ireland) Ltd http://www.openconnect.ie/
Re: Where's the filehandle in a PerlHandler module?
On Wed, Sep 27, 2000 at 04:12:23PM -0700, Clayton Mitchell wrote:
> In a handler I want to process all requests and parse the document
> requested and spit it out after marking it up.
>
> I have put in place this code, but I don't see how to access the actual
> requested document.
>
> I'm hoping there's already an open filehandle to it somewhere?
There's no open filehandle because the file the HTTP client thinks it's
requesting may not actually exist. For example:
SetHandler perl-script
PerlHandler Foo::Bar::Baz
There isn't necessarily a file/directory ${DOCUMENT_ROOT}/foo - the request
is intercepted by mod_perl before it reaches that state.
There are several different methods for looking at and parsing the request
URI. The one that seems right for you is $r->filename()
BTW, this is documented in `perldoc Apache`. Another useful reference is
the mod_perl reference card.
HTH,
Neil
--
Neil Conway <[EMAIL PROTECTED]>
Get my GnuPG key from: http://klamath.dyndns.org/mykey.asc
Encrypted mail welcomed
Violence is to dictatorship as propaganda is to democracy.
-- Noam Chomsky
PGP signature
Where's the filehandle in a PerlHandler module?
Sorry to ask such a newbie question, but I can't figure this out.
In a handler I want to process all requests and parse the document
requested and spit it out after marking it up.
I have put in place this code, but I don't see how to access the actual
requested document.
I'm hoping there's already an open filehandle to it somewhere?
## a simple handler - but doesn't print the actual requested
document.
package _Parse;
sub handler {
my $r = shift;
my $symname;
$r->content_type("text/html");
$r->send_http_header;
$r->print("header text\n");
# this doesn't work ---
while (<>) {
$r->print;
$_->print;
}
# this prints the environment variables
foreach $key (keys %ENV) {
print "$key: $ENV{$key}";
print "";
}
}
1;
Re: Core Dump on "use DBI"
On 20 Sep 2000 [EMAIL PROTECTED] wrote: > I did the same thing (static linking) and it now also works. > > FYI, I was using the Apache httpd out of the box from Redhat. It had > been compiled with http_core, mod_so and no other modules. All modules > (including mod_perl) were dynamically loaded in the httpd.conf file. > > I have a feeling that the bug only exists with DSO's. redhat used to ship a mod_perl dso rpm older than mod_perl-1.22, not sure what versions of things they're at now. 1.22 fixed a but a bug related to pre-loading xs modules, e.g. DBI.
Re: modperl and mutiple Servers
On Wed, 20 Sep 2000, Tobias Dittrich wrote: > Hi, > > I am running Apache Server with mutiple hosts (IP as well as name based) on > a SuSe Linux 6.4 machine. Some of the hosts are running modperl scripts as > well as perl scripts at the same time and they do share the same global > variables (such as Database login/ password etc.) defined in a perl script > that is "required" in ervery script. These hosts are almost identical as > they are mostly the same webshop in different languages but do reside in > different directories. > Now I am experiencing some strange behavior: sometimes one of the hosts is > using the variables of another host. For example the german site logs into > the database as "the english site" and then displays its contents in english > instead of german. After pressing the reload button the correct content is > being displayed. > So my question now is: is it possible that this error is caused by modperl > because all of the scripts have the same scriptnames (even though they do > come from different diretories) and that they are being mixed in memory? And > how could I avoid this without having to rename all of the scripts? I did > not find anything in the documentation/ FAQs of modperl/ Apache but maybe > someone could point me to a doc about modperl/ Perl where this topic is > being covered? it is possible if your mod_perl is older than version 1.23, what version are you using? it's an old bug that should be gone for good in 1.23, i hope it hasn't crept up again.
Re: segfaulting httpd :(
On Thu, 14 Sep 2000, Ben Turner wrote: > > hi all, > > this afternoon i compiled a fresh httpd (apache 1.3.12), together with > mod_perl 1.24. i'm on Solaris 8, running perl 5.6.0. > > after compiling httpd, i'm getting segfaults whenever i do a normal http > request. for instance: stacktrace would help (see SUPPORT for hints). also, your 'perl -V' and Makefile.PL options.
Re: Bad free() ignored?
On Wed, 13 Sep 2000, Eamon Daly wrote: > We've been using mod_perl/DBI for our entire website for just > under a year now (over 1.5M pages a day-- I owe the mod_perl > folks a hell of a lot of beer), and have suddenly started > seeing a small number of "Bad free() ignored" lines appear in > the error logs. My error trapping gives line numbers, but they > don't point to anything obvious. Has anyone else seen this > behavior? if you shared the line numbers and a little about the code with us that would help. so would beer ;) the warning is something common to buggy xs code. > mod_perl 1.26 1.26??
Re: PerlAuthenHandler advice needed.
By choosing to use your custom AuthHandler, you basically override Apache's way of handling the particular phase, in this case the authentication phase. So you must handle prompting the user and also checking the password. You might want to read the Apache Guide (http://perl.apache.org/) on how to write you own handler and also the eagle book. After reviewing our previous conversation, I think you might need to send WWW-Authenticate header field in another phase (preferable at the PerlHeaderParserHandler) before the Authentication phase is called. Your PerlHeaderParserHandler can check the $r->uri for any password protected requests, i.e., if it matches /companyA, you can then set the WWW-Authenticate: Basic $realm and push it along it's merry way. Then your PerlAuthHandler will get the username and password and check it against the realms' AuthUserFile. Apache will handle the initial prompting for the username/password. Your requirements imply that you will have a file(??) that has a list of UserFiles for each Realm/path_info so that your authentication handler will know what file to check against. I hope this make sense ;) my coffee is running low... -Carlos Todd Chapman wrote: Thanks for the help. I was hoping that Apache would check the password for me but this should work. Now, how do I get Apache to run my PerlAuthenHandler without setting the AuthType or AuthName in httpd.conf? Do I need to do the Authentication in a PerlHandler? -Todd On Wed, 27 Sep 2000, Carlos Ramirez wrote: > 1. Oh, I mis-interpreted your question. I thought you already had a list of > virtual directories with the > AuthNames defined. > > You can set the AuthName by sending them in the server response header field: > > WWW-Authenticate Basic $realm > > So the first request to /companyA, you AuthHandler will respond with: > > $r->header_out(WWW-Authenticate => 'Basic $realm); ## Sets Realm field > $r->note_basic_auth_failure; ## Prompts for password > > The when a username and password are supplied i.e. > ($ret,$password) = $r->get_basic_auth_pw; > > where $ret = 1; > > Then: > 1. determine the AuthUserFile > 2. use Apache::Htpasswd to check password > > -Carlos > > > > > > > > Todd Chapman wrote: > > > Problems with your suggestion: > > > > 1. The realm will not be known until I get path_info so > > directives will not work. > > > > 2. How can I get Perl to do the password lookup in the dynamically > > selected AuthUserFile? > > > > Thanks for the help. > > > > -Todd > > > > On Wed, 27 Sep 2000, Carlos Ramirez wrote: > > > > > You can you use Location to specify seperate AuthUserFile's like so: > > > > > > > > > AuthType Basic > > > AuthName CompanyA > > > AuthUserFile path/to/CompanyAUsersFile > > > > > > > > > > > > > > > AuthType Basic > > > AuthName CompanyN > > > AuthUserFile path/to/CompanyNUsersFIle > > > > > > > > > > > > Or you can write your own AuthHandler that lookups up AuthName, AuthUserFile > > > in a seperate file against the path_info. This will eliminate the need to > > > flood you httpd.conf file with a bunch of directives. > > > > > > > > > > > > > > > > > > > > > Todd Chapman wrote: > > > > > > > I have read chapter 6 of the modperl book but still don't know how to set > > > > up authenification the way I want. I would like to use Basic > > > > authentification to protect virtual documents. The trick is that I want > > > > to set AuthName and AuthUserFile based on path_info. > > > > > > > > For example: > > > > > > > > http://virtual/companyA/dir1 > > > > > > > > would prompt for a password in the companyA realm and check it against the > > > > appropriate AuthUserFile. > > > > > > > > How do I add this flexibility without reinventing the parts Apache already > > > > does so well? > > > > > > > > Thanks. > > > > > > > > -Todd > > > > > > -- > > > --- > > > Carlos Ramirez + Boeing + Reusable Space Systems + 714.372.4181 > > > --- > > > - Someday I'll find that peer and reset his connection! > > > > > > > > > > > -- > --- > Carlos Ramirez + Boeing + Reusable Space Systems + 714.372.4181 > --- > - Someday I'll find that peer and reset his connection! > > > -- --- Carlos Ramirez + Boeing + Reusable Space Systems + 714.372.4181 --- - Someday I'll find that peer and reset his connection!
Re: /usr/lib/perl5/5.00503/i386-linux/CORE/perl.h:2546: redefinitionof `union semun'
On Wed, 13 Sep 2000 [EMAIL PROTECTED] wrote: > > Hi all, > > I have some problems with installig mod_perl, > environment: > Redhat 6.1 > perl 5.005_03 (i386 from RPM) > mod_perl-1.24 (source) > apache-1.3.12 (source) > > In file included from mod_perl.h:92, > from mod_perl.c:67: > /usr/lib/perl5/5.00503/i386-linux/CORE/perl.h:2546: redefinition of `union semun' ... > I found some docs about this problem: > http://www.mail-archive.com/modperl%40apache.org/msg02400.html (removing rpm with >perl and install it from source) > http://www.mail-archive.com/dbi-users%40isc.org/msg00351.html (install DBI, I did >it but still the same ) > > Have anyone any good idea?? Or similiar problem? your 'perl -V' might help. also, make sure you start over with freshly unpacked Apache and mod_perl trees now that your Perl has been re-intalled.
Re: SIGSEGV
On Mon, 11 Sep 2000, [iso-8859-1] François Chenais wrote: > Hello > > I have a Segmentation fault error with mod perl ! > Any idea ? > (gdb) run /opt/apache/lib/perl/WCM.pl > Starting program: /usr/bin/perl /opt/apache/lib/perl/WCM.pl ... > Program received signal SIGSEGV, Segmentation fault. that is not mod_perl, it's core dumping under your /usr/bin/perl > #5 0x401b11f1 in ?? () from /opt/apache/lib/perl/PerlSWIP.so no doubt some buggy xs code in this module. if you have the sources, add this to Makefile.PL:WriteMakefile (OPTIMIZE => '-g') then the stacktrace will be more useful (my guess is that sv_setpv() is pass a Nullsv). if you're still stuck, [EMAIL PROTECTED] is the right place for help.
Re: further adventures with taint
At 11:52 AM -0700 9/27/2000, Doug MacEachern wrote: >On Mon, 4 Sep 2000, Michael Blakeley wrote: > >> I've been running with AP616 and Taint On for three days now, and it >> seems to have fixed my problems. I hope so. I really hope so. > >still looking good? would be good to know if this isn't a problem on the >mod_perl side :) Well... there are still taint errors, but they're much less frequent. A grep over the past 30 days shows 5 errors: [Fri Sep 22 05:24:55 2000] [error] Insecure dependency in require while running with -T switch at /usr/local/lib/perl5/site_perl/5.6.0/MIME/Lite.pm line 2145. [Mon Sep 18 13:46:21 2000] [error] Insecure dependency in require while running with -T switch at (eval 258) line 3. [Sat Sep 16 11:14:13 2000] [error] Insecure dependency in require while running with -T switch at /usr/local/lib/perl5/site_perl/5.6.0/MIME/Lite.pm line 2145. [Fri Sep 1 13:05:50 2000] [error] Insecure dependency in require while running with -T switch at /usr/local/lib/perl5/site_perl/5.6.0/MIME/Lite.pm line 2145. [Wed Aug 30 11:07:47 2000] [error] Insecure dependency in require while running with -T switch at /usr/local/lib/perl5/site_perl/5.6.0/MIME/Lite.pm line 2145. The access logs show that we've called that routine 92 times during that period. An error rate of 5.4% isn't thrilling, but it's better than the 99% errors that I saw before applying AP616. It seems that before AP616, the server would run ok for a while, then all queries of this type would err. Now it seems to be more subtle - perhaps the patch causes Perl to clean up its error, so I only get one failure at a time. I don't understand why it reports a line number in some cases, and the eval in others. The access log shows that all these taint errors accessed the same URI with similar inputs. Of course, pointer errors tend to exhibit this kind of unpredictable behavior, and AFAICT "taint" is just a flipped bit inside perl. The line referenced above, BTW, is unexceptional to my eye: require Net::SMTP; So there may still be a lurking post-AP616 bug or two. I'll certainly keep an eye on perl.com and try 5.6.1 when it's released. But I don't really suspect mod_perl at this point. -- Mike
Re: Problems loading POSIX module
On Wed, 30 Aug 2000, erich oliphant wrote:
> Hi,
> I have a script that bombs under modperl when it tries to 'use POSIX'. I
> get the same message when I try to preload it in the httpd.conf. Here's the
> error:
> --
> [Tue Aug 29 15:59:21 2000] [error] Can't load
> '/usr/local/lib/perl5/5.6.0/sun4-solaris/auto/POSIX/POSIX.so' for module
> POSIX: ld.so.1: httpd: fatal: relocation error: file
> /usr/local/lib/perl5/5.6.0/sun4-solaris/auto/POSIX/POSIX.so:
> symbolPL_stack_sp: referenced symbol not found at
can you post the output of the script below, run like so:
% perl perlnm.pl stack_sp POSIX
and your 'perl -V' too.
use Config;
my $sym = shift;
my @modules;
for (@ARGV) {
my $so;
for my $path (@INC) {
if (-e ($so = "$path/auto/$_/$_.so")) {
push @modules, $so;
last;
}
}
}
for ("$Config{archlibexp}/CORE/libperl.a",
"$Config{archlibexp}/CORE/libperl.so",
$Config{perlpath},
@modules)
{
next unless -e $_;
my $cmd = "nm $_ | grep $sym";
print "$cmd\n";
system $cmd;
}
Re: PerlAuthenHandler advice needed.
Thanks for the help. I was hoping that Apache would check the password for me but this should work. Now, how do I get Apache to run my PerlAuthenHandler without setting the AuthType or AuthName in httpd.conf? Do I need to do the Authentication in a PerlHandler? -Todd On Wed, 27 Sep 2000, Carlos Ramirez wrote: > 1. Oh, I mis-interpreted your question. I thought you already had a list of > virtual directories with the > AuthNames defined. > > You can set the AuthName by sending them in the server response header field: > > WWW-Authenticate Basic $realm > > So the first request to /companyA, you AuthHandler will respond with: > > $r->header_out(WWW-Authenticate => 'Basic $realm); ## Sets Realm field > $r->note_basic_auth_failure; ## Prompts for password > > The when a username and password are supplied i.e. > ($ret,$password) = $r->get_basic_auth_pw; > > where $ret = 1; > > Then: > 1. determine the AuthUserFile > 2. use Apache::Htpasswd to check password > > -Carlos > > > > > > > > Todd Chapman wrote: > > > Problems with your suggestion: > > > > 1. The realm will not be known until I get path_info so > > directives will not work. > > > > 2. How can I get Perl to do the password lookup in the dynamically > > selected AuthUserFile? > > > > Thanks for the help. > > > > -Todd > > > > On Wed, 27 Sep 2000, Carlos Ramirez wrote: > > > > > You can you use Location to specify seperate AuthUserFile's like so: > > > > > > > > > AuthType Basic > > > AuthName CompanyA > > > AuthUserFile path/to/CompanyAUsersFile > > > > > > > > > > > > > > > AuthType Basic > > > AuthName CompanyN > > > AuthUserFile path/to/CompanyNUsersFIle > > > > > > > > > > > > Or you can write your own AuthHandler that lookups up AuthName, AuthUserFile > > > in a seperate file against the path_info. This will eliminate the need to > > > flood you httpd.conf file with a bunch of directives. > > > > > > > > > > > > > > > > > > > > > Todd Chapman wrote: > > > > > > > I have read chapter 6 of the modperl book but still don't know how to set > > > > up authenification the way I want. I would like to use Basic > > > > authentification to protect virtual documents. The trick is that I want > > > > to set AuthName and AuthUserFile based on path_info. > > > > > > > > For example: > > > > > > > > http://virtual/companyA/dir1 > > > > > > > > would prompt for a password in the companyA realm and check it against the > > > > appropriate AuthUserFile. > > > > > > > > How do I add this flexibility without reinventing the parts Apache already > > > > does so well? > > > > > > > > Thanks. > > > > > > > > -Todd > > > > > > -- > > > --- > > > Carlos Ramirez + Boeing + Reusable Space Systems + 714.372.4181 > > > --- > > > - Someday I'll find that peer and reset his connection! > > > > > > > > > > > -- > --- > Carlos Ramirez + Boeing + Reusable Space Systems + 714.372.4181 > --- > - Someday I'll find that peer and reset his connection! > > >
SegFault with Apache::Include
I am having some problems with Apache::Include.
When I include more than one file with it, the httpd seg faults.
The script can be as simple as this:
#!/usr/bin/perl
use Apache::Include ();
print "Content-type: text/html\n\n";
Apache::Include->virtual('/perl-bin/helloworld');
Apache::Include->virtual('/perl-bin/helloworld');
Where /perl-bin/helloworld only prints "Hello World".
This gives me
[notice] child pid 588 exit signal Segmentation fault (11)
It works fine when I only include one script.
I've been trying to trace and debug, but I get nowhere.
Do anyone know a solution for this?
I'm using Apache/1.3.12 , Linux
Thanks in advance / Magnus
Apache::ASP error
I installed Apache::ASP. When test with a simple asp page. I got an internal server error and the error_log says: [Wed Sep 27 02:11:07 2000] [error] Can't locate Apache/ASP.pm in @INC (@INC contains: G:/Program Files/Apache Group/Perl/5.6.0/lib/MSWin32-x86 G:/Program Files/Apache Group/Perl/5.6.0/lib G:/Program Files/Apache Group/Perl/site/5.6.0/lib/MSWin32-x86 G:/Program Files/Apache Group/Perl/site/5.6.0/lib . /apache/ /apache/lib/perl) at (eval 4) line 3. [Wed Sep 27 02:11:07 2000] [error] Undefined subroutine &Apache::ASP::handler called. Thanks. __ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/
Seg Fault with Apache::Include
I am having some problems with Apache::Include.
When I include more than one file with it, the httpd seg faults.
The script can be as simple as this:
#!/usr/bin/perl
use Apache::Include ();
print "Content-type: text/html\n\n";
Apache::Include->virtual('/perl-bin/helloworld');
Apache::Include->virtual('/perl-bin/helloworld');
Where /perl-bin/helloworld only prints "Hello World".
This gives me
[notice] child pid 588 exit signal Segmentation fault (11)
It works fine when I only include one script.
I've been trying to trace and debug, but I get nowhere.
Do anyone know a solution for this?
I'm using Apache/1.3.12 , Linux
Thanks in advance / Magnus
Re: PerlAuthenHandler advice needed.
1. Oh, I mis-interpreted your question. I thought you already had a list of virtual directories with the AuthNames defined. You can set the AuthName by sending them in the server response header field: WWW-Authenticate Basic $realm So the first request to /companyA, you AuthHandler will respond with: $r->header_out(WWW-Authenticate => 'Basic $realm); ## Sets Realm field $r->note_basic_auth_failure; ## Prompts for password The when a username and password are supplied i.e. ($ret,$password) = $r->get_basic_auth_pw; where $ret = 1; Then: 1. determine the AuthUserFile 2. use Apache::Htpasswd to check password -Carlos Todd Chapman wrote: Problems with your suggestion: 1. The realm will not be known until I get path_info so directives will not work. 2. How can I get Perl to do the password lookup in the dynamically selected AuthUserFile? Thanks for the help. -Todd On Wed, 27 Sep 2000, Carlos Ramirez wrote: > You can you use Location to specify seperate AuthUserFile's like so: > > > AuthType Basic > AuthName CompanyA > AuthUserFile path/to/CompanyAUsersFile > > > > > AuthType Basic > AuthName CompanyN > AuthUserFile path/to/CompanyNUsersFIle > > > > Or you can write your own AuthHandler that lookups up AuthName, AuthUserFile > in a seperate file against the path_info. This will eliminate the need to > flood you httpd.conf file with a bunch of directives. > > > > > > > Todd Chapman wrote: > > > I have read chapter 6 of the modperl book but still don't know how to set > > up authenification the way I want. I would like to use Basic > > authentification to protect virtual documents. The trick is that I want > > to set AuthName and AuthUserFile based on path_info. > > > > For example: > > > > http://virtual/companyA/dir1 > > > > would prompt for a password in the companyA realm and check it against the > > appropriate AuthUserFile. > > > > How do I add this flexibility without reinventing the parts Apache already > > does so well? > > > > Thanks. > > > > -Todd > > -- > --- > Carlos Ramirez + Boeing + Reusable Space Systems + 714.372.4181 > --- > - Someday I'll find that peer and reset his connection! > > > -- --- Carlos Ramirez + Boeing + Reusable Space Systems + 714.372.4181 --- - Someday I'll find that peer and reset his connection!
Re: Passing STDIN to subprogram
On Wed, 6 Sep 2000, erich oliphant wrote:
> I am replacing a CGI shell script with a modperl script. At one point in
> the shell script subprogram is called. The HTML form that calls the script
> calls it via a POST. As such the params are available via STDIN. The
> subprogram call (which I can't eliminate yet) expects to see the form
> params. However when I call it from the perl script STDIN is empty. I have
> tried backticks and the open call (which are supposed to inherit STDIN) to
> no avail.
STDIN cannot be passed to a subprocess, because STDIN is not stdin under
mod_perl. that is, it's not a file descriptor, it's just a Perl glob,
that's tie-d to the Apache request_rec + api. one solution would be to do
switch the POST to a GET:
local $ENV{PATH} = '/home/dougm/bin';
my $r = shift;
$r->send_http_header;
local $ENV{GATEWAY_INTERFACE} = 'CGI/1.1'; #hmm, shouldn't need todo this
local $ENV{QUERY_STRING} = $r->content;
local $ENV{REQUEST_METHOD} = 'GET';
local $ENV{CONTENT_LENGTH} = 0;
print `cgi-dump`;
where cgi-dump is:
#!/usr/local/bin/perl
use CGI ();
my $q = CGI->new;
print $q->as_string;
works just fine:
% POST http://localhost:8529/perl/post.pl
Please enter content (application/x-www-form-urlencoded) to be POSTed:
one=1
one
1
Re: Bug? in mod_perl when POST request yields REDIRECT
take 2 on that patch, this one adds a check so ap_setup_client_block() is
only called once. with this part of the fix you can call $r->content
multiple times without hanging:
my $data = $r->content;
$data = $r->content;
however, any calls to $r->content after the first will return undef.
(unless you happen to subclass and override the content method to cache
the read data somewhere)
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.109
diff -u -r1.109 Apache.xs
--- src/modules/perl/Apache.xs 2000/09/27 16:25:56 1.109
+++ src/modules/perl/Apache.xs 2000/09/27 19:38:34
@@ -954,22 +954,27 @@
int bufsiz
PREINIT:
-long nrd = 0;
+long nrd = 0, old_read_length;
int rc;
PPCODE:
-if ((rc = setup_client_block(r, REQUEST_CHUNKED_ERROR)) != OK) {
- aplog_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO, r->server,
- "mod_perl: setup_client_block failed: %d", rc);
- XSRETURN_UNDEF;
+if (!r->read_length) {
+if ((rc = setup_client_block(r, REQUEST_CHUNKED_ERROR)) != OK) {
+aplog_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO, r->server,
+"mod_perl: setup_client_block failed: %d", rc);
+XSRETURN_UNDEF;
+}
}
+old_read_length = r->read_length;
+r->read_length = 0;
+
if (should_client_block(r)) {
SvUPGRADE(buffer, SVt_PV);
SvGROW(buffer, bufsiz+1);
nrd = get_client_block(r, SvPVX(buffer), bufsiz);
-r->read_length = 0;
-}
+}
+r->read_length += old_read_length;
if (nrd > 0) {
XPUSHs(sv_2mortal(newSViv((long)nrd)));
Re: Bug? in mod_perl when POST request yields REDIRECT
On Wed, 6 Sep 2000, Reif Peter wrote:
> I am using a self written mod_perl module that does proxy requests. It acts
> as content handler and fetches the requestet documents via LWP::UserAgent.
> The program works fine but when the request is a POST request and the
> response is a redirection (301, 302, ...) with a Location: header, no data
> is sent to the browser.
>
> If I don't read the postet data, everything works. So my suspicion is the
> following:
> For any reason, if the module returns a redirecting result code (301, 302,
> ...), mod_perl tries to read again the posted data and waits forever.
>
> My solution is simple: Just set the Content-lengt: header to undef:
>
> $r->header_in('Content-length' => undef);
>
> Is this a bug or a feature?
it's a known issue, from the ToDo:
"- should $r->content unset $r->headers_in('content-length') ?
NOTE: im worried this could break apps who need to know content-length
after data has been read"
looking at mod_perl Changes:
=item 1.00b2 - 07/07/97
...
make compatible with 1.2.1 r->read_length change so we don't hang
on file uploads
the problem is that a drastic api change in Apache was made around that
time, which we had to fit into Perl's api. ap_setup_client_block() and
ap_should_client_block() are only supposed to be called once according to
the api spec. Apache.xs calls them everytime $r->read is called, and the
change above was setting r->read_length = 0; so ap_setup_client_block()
would return true the second time it is called. when a redirect or error
is thrown, ap_discard_request_body() also checks ap_should_client_block()
which returns true because we've set r->read_length = 0;
so, i think a reasonable fix for now is to localize the r->read_length
change with this patch:
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.109
diff -u -r1.109 Apache.xs
--- src/modules/perl/Apache.xs 2000/09/27 16:25:56 1.109
+++ src/modules/perl/Apache.xs 2000/09/27 19:19:20
@@ -954,7 +954,7 @@
int bufsiz
PREINIT:
-long nrd = 0;
+long nrd = 0, old_read_length;
int rc;
PPCODE:
@@ -964,12 +964,15 @@
XSRETURN_UNDEF;
}
+old_read_length = r->read_length;
+r->read_length = 0;
+
if (should_client_block(r)) {
SvUPGRADE(buffer, SVt_PV);
SvGROW(buffer, bufsiz+1);
nrd = get_client_block(r, SvPVX(buffer), bufsiz);
-r->read_length = 0;
-}
+}
+r->read_length += old_read_length;
if (nrd > 0) {
XPUSHs(sv_2mortal(newSViv((long)nrd)));
Re: PerlAuthenHandler advice needed.
Problems with your suggestion: 1. The realm will not be known until I get path_info so directives will not work. 2. How can I get Perl to do the password lookup in the dynamically selected AuthUserFile? Thanks for the help. -Todd On Wed, 27 Sep 2000, Carlos Ramirez wrote: > You can you use Location to specify seperate AuthUserFile's like so: > > > AuthType Basic > AuthName CompanyA > AuthUserFile path/to/CompanyAUsersFile > > > > > AuthType Basic > AuthName CompanyN > AuthUserFile path/to/CompanyNUsersFIle > > > > Or you can write your own AuthHandler that lookups up AuthName, AuthUserFile > in a seperate file against the path_info. This will eliminate the need to > flood you httpd.conf file with a bunch of directives. > > > > > > > Todd Chapman wrote: > > > I have read chapter 6 of the modperl book but still don't know how to set > > up authenification the way I want. I would like to use Basic > > authentification to protect virtual documents. The trick is that I want > > to set AuthName and AuthUserFile based on path_info. > > > > For example: > > > > http://virtual/companyA/dir1 > > > > would prompt for a password in the companyA realm and check it against the > > appropriate AuthUserFile. > > > > How do I add this flexibility without reinventing the parts Apache already > > does so well? > > > > Thanks. > > > > -Todd > > -- > --- > Carlos Ramirez + Boeing + Reusable Space Systems + 714.372.4181 > --- > - Someday I'll find that peer and reset his connection! > > >
Re: Strange error message: (offline mode: enter name=value pairs on standard input)
i think you'll find the answer here. http://www.geocrawler.com/archives/3/182/2000/5/0/3817939/ -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/ MJ M wrote: > Hello, > > I have recently made the following upgrade: > > apache-1.3.6 --> apache-1.3.12 > perl-5.005_02 --> perl-5.6 > mod_perl-1.18 --> mod_perl-1.24 > > Except this upgrade, nothing else was changed. Since then, I frequently get > the following message in the Apache error > log (this message never occured before the upgrade): > > (offline mode: enter name=value pairs on standard input)
Re: further adventures with taint
On Mon, 4 Sep 2000, Michael Blakeley wrote: > I've been running with AP616 and Taint On for three days now, and it > seems to have fixed my problems. I hope so. I really hope so. still looking good? would be good to know if this isn't a problem on the mod_perl side :)
Re: compiling mod_perl for solaris
On Fri, 1 Sep 2000, Joseph Sirucka - Netics wrote: > Hi People > > I've been trying to compile mod_perl for solaris 8 recently and I > recompiled perl 5.6.0 with _ubincompat5005 and -Uuselargefiles. > > But no matter what I do with with mod_perl to compile it at > perl Makefile.PL blah i get this error > > ld.so.1: perl: fatal: relocation error: file > /usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris/auto/HTML/Parser/Parser.so: > > symbol perl_get_hv: referenced symbol not found > Killed if you recompiled Perl with -Ubincompat5005, then you also need to recompile any xs site-perl modules, e.g. HTML::Parser
Re: Apache.xs patch for get_client_block
On 31 Aug 2000 [EMAIL PROTECTED] wrote: > Btw: I've been playing with the keep-alive stuff you left lying around > in Connection.xs. The naive implementation I made seems to work fine, > once the headers are sent to the client. Are you planning to add them > in the next mod_perl release? you mean this? # int keepalive; /* Are we using HTTP Keep-Alive? */ # int keptalive; /* Did we use HTTP Keep-Alive? */ # int keepalives; /* How many times have we used it? */ i have no plans for adding hooks to those unless they're useful in someway. have you found a use?
Re: PassEnv (passing everything)
On Thu, 31 Aug 2000, erich oliphant wrote:
> Hi,
> I am porting a shell script CGI to mod_perl. It uses a great many
> environment variables. I'm new to the project so figuring out which
> variables to pass is rather tedious. Does PassEnv support wildcards
> (PassEnv *) or some option to pass the entire parent environment?
the Perl %ENV is cleared during startup, but the C environment is left in
tact. with a combo of forking `env` and sections you can do this.
for example, this passes all environment variables that begin with the
letter H:
local $ENV{PATH} = '/usr/bin';
local $_;
for (`env`) {
next unless /^(H.*)=/;
push @PassEnv, $1;
}
Re: PerlAuthenHandler advice needed.
You can you use Location to specify seperate AuthUserFile's like so: AuthType Basic AuthName CompanyA AuthUserFile path/to/CompanyAUsersFile AuthType Basic AuthName CompanyN AuthUserFile path/to/CompanyNUsersFIle Or you can write your own AuthHandler that lookups up AuthName, AuthUserFile in a seperate file against the path_info. This will eliminate the need to flood you httpd.conf file with a bunch of directives. Todd Chapman wrote: I have read chapter 6 of the modperl book but still don't know how to set up authenification the way I want. I would like to use Basic authentification to protect virtual documents. The trick is that I want to set AuthName and AuthUserFile based on path_info. For example: http://virtual/companyA/dir1 would prompt for a password in the companyA realm and check it against the appropriate AuthUserFile. How do I add this flexibility without reinventing the parts Apache already does so well? Thanks. -Todd -- --- Carlos Ramirez + Boeing + Reusable Space Systems + 714.372.4181 --- - Someday I'll find that peer and reset his connection!
Re: perlfilter + mod_perl ?
see the message i just posted: [EMAIL PROTECTED]">http://forum.swarthmore.edu/epigone/modperl/dorsnoidwimp/[EMAIL PROTECTED] On Sat, 16 Sep 2000, Norbert Csongradi wrote: > Hi ! > > I created an encryption filter based on perlfilter > (CPAN/modules/by-module/Filter by Paul Marquess). > It's working very well in standard perl enviroment (command line, webserver > without mod_perl enabled), but it does not work with mod_perl. > It seems to be that it cannot modificate the source while mod_perl interpreter > reads in the file, so all the data is read as-is and mod_perl exists with > unrecognised character, etc. > I have several sites running entirely on mod_perl, so I was not so happy > with this feature :(. > > Does anybody have any experience with it ? > > Big thx in advance, > Bert > >
Re: Wanted: a few testers for libapreq on Win32
On Wed, 27 Sep 2000, Jiho Hahm wrote: > Hi, I just packaged up and sent to Doug the changes I made to mod_perl > and libapreq to make libapreq work on Win32, but I haven't had a chance > to test it thoroughly. I know there are at least several of you out > there who want to use Apache::Request on Win32, so if you want to > volunteer as a tester, email me directly and I'll send you the files. > > The things that need testing are: > > - the correctness of INSTALL.win32 file > - does it build OK on people's machines? > - did it break build on other platforms? > - Apache::Request and Apache::Cookie functionality in general > > So far I've only verified that: > > - it builds on my NT machine > - form data parsing and file upload; no testing on cookies > > -Jiho > Hi, For Win32 ActivePerl users, there's also a ppm version of libapreq that can be installed by ppm install http://theoryx5.uwinnipeg.ca/ppmpackages/libapreq.ppd This needs the latest cvs mod_perl to build, and passed the mod_perl request.t and cookie.t tests (with a "binmode" inserted in request.t after opening "FH"). It would be good though to test this more. best regards, randy kobes
Re: Installation problem...
On Thu, 31 Aug 2000, Derrick wrote: > Dear all, > This is my second time sending this email with the same content. If anybody > know how to fix my problem, please let me know. Thanks. > I am trying to install mod-perl on my freebsd 4.0 server with stronghold and > lastest modperl from cvs. I keep having the same error as follow: > `XS_Apache__Util_validate_password': > Util.o(.text+0x7ac): undefined reference to `ap_validate_password' ... > Stop in /usr/local/stronghold/src. i guess your stronghold is an *old* version of apache. you can solve by using Makefile.PL PERL_UTIL_API=0 or just remove these 4 lines from Util.xs: int validate_password(passwd, hash) const char *passwd const char *hash
Re: statically linked Perl
On Thu, 31 Aug 2000, Todd Caine wrote: > Hi, folks. > > I'm having a problem building a statically linked perl (yes, > I know, but I > need it for XS debugging). MakeMaker is trying to link the > static binary > with libapreq.a, which is okay, but libapreq.a doesn't > export a bootstrap > symbol boot_libapreq(). The perlmain.c generated by by > Makefile.aperl > contains a call to the boot_libapreq() function. > > I assume this is because libapreq.a is found in the > 5.6.0/auto directory. > A quick check shows this is the only .a file in that > directory. libapreq > appears to be related to Apache and/or mod_perl (APache > REQuest). > > I can build the static perl successfully if I manually > delete the call in > perlmain.c to boot_libapreq(). However, it's inconvenient > and clearly > bogus to have to do this every time. you either have to do that or just delete: > /usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris/auto/libapreq/libapreq.a it's only installed for C modules to link against, but the next version of libapreq will probably not do that, since there is autoconf support in place for C module authors.
Re: Filter::decrypt under Apache::Registry.
On Thu, 10 Aug 2000, Leonardo Madrigal wrote: > Hi everyone! > > I have a bunch of scripts that i need to protect (source code), i do > know that Filter::decrypt is not the best tool around for this > matter...but still i want to use it. > > I have those scripts running under Apache::Registry, they worked fine > till i encrypt them with Filter::, but now every time that someone > tries to execute a script seems like mod_perl is not trying > Filter::decrypt cause i get this on the logs > > [Thu Aug 10 17:42:34 2000] [error] Unrecognized character \377 at > /usr/local/apache/spfs/index.cgi line 2. > > Does anybody knows how to fix this??? the problem is that Perl's eval "" function does not support filters and Apache::Registry uses eval "" to compile scripts. one solution would be to wrap your crypted code in a module, consisting of only subroutines and the main body of the code moved into a routine named main(). then have a registry script to run it: use MyModule::EncryptedWithFilterCrypt (); MyModule::EncryptedWithFilterCrypt::main(); or, have your registry script pull in the encrypted script with do: do 'encrypted-script.pl'; but you loose some perfomance because the script is decrypted and compiled for every request. another solution is to not use Apache::Registry at all and move your script into a handler.
[WOT] MakeMaker
This is Way Off Topic, but I'm guessing module writers here may be able to help. I posted this question a few other places first without luck, so I apologize if it looks familiar. I'm trying to figure out how to keep MakeMaker from building a Makefile that access subdirectories. I like keeping the directory structure for building the related modules, but I'd like to work with them independently. That is, I'd like to be able to make clean or make test in the top directory and not have it work on the directories below. I've set 'NORECURS' => 1, in Makefile.PL and that keeps perl Makefile.PL from recursing, but the resulting Makefile still contains references to the subdirectories: > fgrep bak Makefile @cd pfe.bak && $(MAKE) all $(PASTHRU) -cd pfe.bak && $(TEST_F) Makefile && $(MAKE) clean ... How do you deal with this? Bill Moseley mailto:[EMAIL PROTECTED]
Wanted: a few testers for libapreq on Win32
Hi, I just packaged up and sent to Doug the changes I made to mod_perl and libapreq to make libapreq work on Win32, but I haven't had a chance to test it thoroughly. I know there are at least several of you out there who want to use Apache::Request on Win32, so if you want to volunteer as a tester, email me directly and I'll send you the files. The things that need testing are: - the correctness of INSTALL.win32 file - does it build OK on people's machines? - did it break build on other platforms? - Apache::Request and Apache::Cookie functionality in general So far I've only verified that: - it builds on my NT machine - form data parsing and file upload; no testing on cookies -Jiho
$r->user vs. $r->connection->user
i've added an $r->user method as an alias to $r->connection->user, now that `user' hangs off of the request_rec rather than request_rec->connection in Apache 2.0 so by the time mod_perl-2.0 is ready to use, auth modules can work with both versions. for backwards compat you can use something like: use constant R_USER => $mod_perl::VERSION >= 1.24_01; my $user = R_USER ? $r->user : $r->connection->user; which of course is optimized by the Perl compiler down to: my $user = $r->user; or my $user = $r->connection->user; for older versions. then again, by the time mod_perl-2.0 is ready you should be safe to say: use mod_perl 1.25; #require version 1.25 or higher my $user = $r->user;
Re: Problem using ADD_MODULE option in Makefile.PL
On Thu, 3 Aug 2000, Nelson Oliveira wrote:
> When you use the ADD_MODULE option to pass an additional
> module to Apache, in the top Makefile.PL of mod_perl,
> like
>
> perl Makefile.PL ADD_MODULE=src/modules/jserv/libjserv.a
>
> this will result in the wrong argument to the configure script
> of Apache, like
>
> ... configure --enable-module=src
>
> The correct argument should have been
>
> ... configure --activate-module=src/modules/jserv/libjserv.a
>
> To fix this problem, apply the included patch to Makefile.PL
> I only changed the order in which the pattern matching is
> performed, because the pattern
> /([a-zA-Z0-9][a-zA-Z0-9_]*)/
>
> will always match this string first, which is not what I want
>
>src/modules/jserv/libjserv.a
>
> I applied the fast fix, by changing the order of the pattern
> matchine, but I think by using this pattern as the first
> /([a-zA-Z0-9][a-zA-Z0-9_]*$)/
>
> the problem is solved as well.
thanks, i think this patch is the right way to go:
Index: Makefile.PL
===
RCS file: /home/cvs/modperl/Makefile.PL,v
retrieving revision 1.168
diff -u -r1.168 Makefile.PL
--- Makefile.PL 2000/09/26 21:19:33 1.168
+++ Makefile.PL 2000/09/27 17:52:12
@@ -975,10 +975,10 @@
}
if($ADD_MODULE) {
for (split ",", $ADD_MODULE) {
- if(/([a-zA-Z0-9][a-zA-Z0-9_]*)/) {
+ if(/^([a-zA-Z0-9][a-zA-Z0-9_]+)$/) {
$cmd .= " --enable-module=$1";
}
- elsif(m:(src/modules/[^/]+/[a-zA-Z0-9][a-zA-Z0-9_]*):) {
+ elsif(m:(src/modules/[^/]+/[^/]+)$:) {
$cmd .= " --activate-module=$1";
}
}
PerlSendHeader Off & socket persistence (was Re: question: using Apache for non-HTML messages)
When I set PerlSendHeader to Off in my perl.conf it doesn't send headers, which is good. The bad part is that it seems to break socket persistence for some reason. When I have PerlSendHeader set to On, I can open a socket with my test client, and make multiple queries on the same socket. Any ideas to help me keep the socket open? Thanks, Brian Doug MacEachern wrote: > On Mon, 25 Sep 2000, B. Burke wrote: > > > I've been able to basically remove the response headers by removing the > > functionality > > of ap_sen_header_field() before compiling Apache, but it would be nice to > > you don't have to remove anything, just don't call $r->send_http_header > and make sure PerlSendHeader is configured to Off, then Apache will not > send any headers.
PerlAuthenHandler advice needed.
I have read chapter 6 of the modperl book but still don't know how to set up authenification the way I want. I would like to use Basic authentification to protect virtual documents. The trick is that I want to set AuthName and AuthUserFile based on path_info. For example: http://virtual/companyA/dir1 would prompt for a password in the companyA realm and check it against the appropriate AuthUserFile. How do I add this flexibility without reinventing the parts Apache already does so well? Thanks. -Todd
Re: Why isn't PerlSetEnv working for me?
Chris Winters wrote: > > * Keith G. Murphy ([EMAIL PROTECTED]) [000926 18:43]: > > I'm running Apache 1.3.9 with mod_perl embedded, on Debian GNU/Linux. > > > > I have the following lines towards the end of my httpd.conf: > > > > PerlSetEnv PERL5LIB /usr/local/MyPerl/lib > > PerlRequire startup.pl > > Include perllocs.conf > > > > However, upon system startup, my startup.pl fails because it can't find > > a particular module in the @INC list. > > > > If I start Apache from the command line, it works. This is undoubtedly > > because PERL5LIB is set up in my /etc/profile, to the same path. > > > > I've looked at this until I'm crosseyed. Seemingly PerlSetEnv just > > doesn't work. > > > > Any ideas? Yes, I know the workaround: 'use lib' in startup.pl. But > > why? > > There's another workaround: > > in httpd.conf: > > > use lib qw( /usr/local/MyPerl/lib ); > > > Pretty painless :) > That's a great workaround (from both Chrises), that I will use. :-) Thanks.
Re: Why isn't PerlSetEnv working for me?
Stas Bekman wrote:
>
> On Tue, 26 Sep 2000, Keith G. Murphy wrote:
>
> > I'm running Apache 1.3.9 with mod_perl embedded, on Debian GNU/Linux.
> >
> > I have the following lines towards the end of my httpd.conf:
> >
> > PerlSetEnv PERL5LIB /usr/local/MyPerl/lib
> > PerlRequire startup.pl
> > Include perllocs.conf
> >
> > However, upon system startup, my startup.pl fails because it can't find
> > a particular module in the @INC list.
> >
> > If I start Apache from the command line, it works. This is undoubtedly
> > because PERL5LIB is set up in my /etc/profile, to the same path.
> >
> > I've looked at this until I'm crosseyed. Seemingly PerlSetEnv just
> > doesn't work.
> >
> > Any ideas? Yes, I know the workaround: 'use lib' in startup.pl. But
> > why?
> >
>
> http://thingy.kcilink.com/modperlguide/config/PerlSetVar_PerlSetEnv_and_PerlP.html
Yes, I have looked at that.
>
> Regarding the setting of PerlPassEnv PERL5LIB in httpd.conf: if you turn
> on taint checks (PerlTaintCheck On), $ENV{PERL5LIB} will be ignored
> (unset). See the 'Switches -w, -T' section.
>
I can explicitly set it *off*:
PerlTaintCheck Off
and still get the same behavior.
Upon further investigation, what I am seeing is that PERL5LIB gets
passed into %ENV just fine. It's just not being used to locate modules;
it is not in @INC. Could the part of Perl that pushes the PERL5LIB
setting to @INC have already executed prior to my PerlSetEnv statement?
If so, that would certainly limit the usefulness of PerlSetEnv for that
purpose. Maybe some note should be made in the docs. Or can someone
confirm that it works for them?
Re: tracking down why a module was loaded?;
Matt Sergeant wrote: > > On Wed, 27 Sep 2000, Matthew Byng-Maddick wrote: > > > > We all have to do our part to evangelize mod_perl more. I think ISPs are > > > really key here as I think I may have mentioned before. If you get the ISPs > > Actually I think the people we need to get involved are the web site > builders - the larger companies offering dynamic web content creation. We > also need some more mainstream tools, the oft-requested "Zope-a-like" in > Perl. And it needs to be trivial to install (I'm not sure how likely that > is to be yet). Hum - most commercial companies that I know in London (few I know), either use ASP (the M$ version) or PHP. The best solution for them is often not what is technically the best, but the compromise of staff cost / availability, and hence development cost. e.g. I have a few friends whom work in ASP shops whom know little about the web in terms of cookies, sessions, headers, but they all know how to set a session in ASP, and hence get the job done. Their employers get the job done, at a lower cost (IMHO ASP programmers are paid less than perl ones). The fact that they often get stuck when trying to do something a little out of the ordinary does not appear to matter much! As for a "Zope-a-like" or similar, I agree that there are few mod_perl applications out there, and judging by the number of PHP apps on freshmeat there's allot of competition. A (or many) flagship application(s) would help evangelise mod_perl allot. On the easy to install front, I think that's due to programmer being lazy. I know there are issues, but making a module install using h2xs stuff is easy (both for programmer and end user). Supplying example httpd.conf files is also easy - it just takes time. > > > advertise support for mod_perl? How many without charging like US$100 more > > > a month on top of the normal account fees? > > > > This is difficult, due to the security issues. If you have client cgi, you > > can always use something like suEXEC or even something as complex as userv > > to run your cgi scripts. With mod_perl, the plugged in scripts can do > > anything that the webserver can, and you can (by writing a module that > > doesn't compile) break the entire webserver. > > > > > PHP comes with a lot of ISP accounts for free with no extra cost. Java does > > > not yet, but I've started seeing ISPs starting to support Java in the low > > > end shared server accounts... > > > > Wow. I'm surprised, for the security reasons I've outlined above. But then > > I don't know much about PHP, really. > > PHP can runs as a normal CGI, using suExec. So it's like advertising Perl > support. > > What would help mod_perl is a working sandboxing system, based on Safe and > SafeHole. I've advocated that idea before, but still don't have the time > to go and build it. With that sort of system, and ISP could easily trap or > prevent whatever they need to, and we could work with them to build up > secure proffessional installations. > > However, I'm honestly not sure if the whole of mod_perl is "right" for the > majority of small fee ISP's. What the ISP's need is perhaps one of the > mod_perl modules, like Mason, Embperl or AxKit, or something like > that. Rather than letting users write PerlInitHandlers! Unfortunately I > have no idea how you might secure one of these modules, even though one is > my own. Because mod_perl is so far entrenched into apache it is difficult to sandbox it. I've looked at running it for a hosting service and it was less than easy, nor eligant to allow users access to mod_perl. I agree with Matt's last point that mod_perl may not be right for the mainstream "free ISP's". After all with performance comes power, and in an ISP's world do you want your webserver going wild due to a badly written bit of perl ? mod_perl is ideal for single use servers that host one application, tailor made for that client (as in customer not http). IMHO mod_perl cannot be beaten on performance or flexibilty in this scenario. Should we not promote mod_perl as a web platform for the 'cognisenti'. After all, all the 'best' things are usually not the most popular, but most people know they are the best. Perhaps this last bit is where the mod_perl 'marketing machine' is failing. just by 2 pence worth. Greg Cope > > -- > > > Fastnet Software Ltd. High Performance Web Specialists > Providing mod_perl, XML, Sybase and Oracle solutions > Email for training and consultancy availability. > http://sergeant.org | AxKit: http://axkit.org
Strange error message: (offline mode: enter name=value pairs on standard input)
Hello, I have recently made the following upgrade: apache-1.3.6 --> apache-1.3.12 perl-5.005_02 --> perl-5.6 mod_perl-1.18 --> mod_perl-1.24 Except this upgrade, nothing else was changed. Since then, I frequently get the following message in the Apache error log (this message never occured before the upgrade): (offline mode: enter name=value pairs on standard input) This message is normally generated by the CGI module when a script using this module is run on the command line. I use CGI in several Apache modules and cgi scripts run under Apache::Registry. Can someone tell me how I can solve this problem ? Best regards. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com.
Re: tracking down why a module was loaded?;
On Wed, 27 Sep 2000, Matt Sergeant wrote: > On Wed, 27 Sep 2000, Matthew Byng-Maddick wrote: > Actually I think the people we need to get involved are the web site > builders - the larger companies offering dynamic web content creation. We > also need some more mainstream tools, the oft-requested "Zope-a-like" in > Perl. And it needs to be trivial to install (I'm not sure how likely that > is to be yet). This is roughly the kind of company I work for, so agreed. > > > PHP comes with a lot of ISP accounts for free with no extra cost. Java does > > > not yet, but I've started seeing ISPs starting to support Java in the low > > > end shared server accounts... > > Wow. I'm surprised, for the security reasons I've outlined above. But then > > I don't know much about PHP, really. > PHP can runs as a normal CGI, using suExec. So it's like advertising Perl > support. Right. > What would help mod_perl is a working sandboxing system, based on Safe and > SafeHole. I've advocated that idea before, but still don't have the time > to go and build it. With that sort of system, and ISP could easily trap or > prevent whatever they need to, and we could work with them to build up > secure proffessional installations. Schwern and I were discussing a new mechanism for a sandbox in Perl6, but unfortunately, I'm not sure how trivial it would be for Perl5, and also, you have to wonder whether any improvement will take away any performance advantage that mod_perl gives you. > However, I'm honestly not sure if the whole of mod_perl is "right" for the > majority of small fee ISP's. What the ISP's need is perhaps one of the > mod_perl modules, like Mason, Embperl or AxKit, or something like > that. Rather than letting users write PerlInitHandlers! Unfortunately I > have no idea how you might secure one of these modules, even though one is > my own. With difficulty. :) that wasn't helpful - but we really need a perl sandboxing mechanism. (perhaps if you can use safe to restrict open(), socket(), creat() etc, then you're doing the right thing) MBM -- UNIX is hot. It's more than hot. It's steaming. It's quicksilver lightning with a laserbeam kicker. -- Michael Jay Tucker
Re: tracking down why a module was loaded?;
On Wed, 27 Sep 2000, Matthew Byng-Maddick wrote: > > We all have to do our part to evangelize mod_perl more. I think ISPs are > > really key here as I think I may have mentioned before. If you get the ISPs Actually I think the people we need to get involved are the web site builders - the larger companies offering dynamic web content creation. We also need some more mainstream tools, the oft-requested "Zope-a-like" in Perl. And it needs to be trivial to install (I'm not sure how likely that is to be yet). > > advertise support for mod_perl? How many without charging like US$100 more > > a month on top of the normal account fees? > > This is difficult, due to the security issues. If you have client cgi, you > can always use something like suEXEC or even something as complex as userv > to run your cgi scripts. With mod_perl, the plugged in scripts can do > anything that the webserver can, and you can (by writing a module that > doesn't compile) break the entire webserver. > > > PHP comes with a lot of ISP accounts for free with no extra cost. Java does > > not yet, but I've started seeing ISPs starting to support Java in the low > > end shared server accounts... > > Wow. I'm surprised, for the security reasons I've outlined above. But then > I don't know much about PHP, really. PHP can runs as a normal CGI, using suExec. So it's like advertising Perl support. What would help mod_perl is a working sandboxing system, based on Safe and SafeHole. I've advocated that idea before, but still don't have the time to go and build it. With that sort of system, and ISP could easily trap or prevent whatever they need to, and we could work with them to build up secure proffessional installations. However, I'm honestly not sure if the whole of mod_perl is "right" for the majority of small fee ISP's. What the ISP's need is perhaps one of the mod_perl modules, like Mason, Embperl or AxKit, or something like that. Rather than letting users write PerlInitHandlers! Unfortunately I have no idea how you might secure one of these modules, even though one is my own. -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: tracking down why a module was loaded?;
On Wed, 27 Sep 2000, Gunther Birznieks wrote: > At 10:28 PM 9/26/2000 +0200, Alexander Farber (EED) wrote: > >Doug MacEachern wrote: > > > > modperl is the best kept secret on the net. Shame! > > > seems to generate plenty of list traffic for a "secret" ;) > >Don't you all think, that mod_perl isn't promoted enough and > >this will kill it someday, despite its technical goodness? Perl in general too, although I disagree with Stas on this one. (we discussed it in the pub on the first night of the conference). > >- There are no articles in the "mainstream" computer press > > (like cnet.com, www.ix.de, etc) about mod_perl. True, but then you need to explain the apache phenomenon first, and too many corporates want to deal only with corporates, making them feel a need to use IIS (with no mod_perl :/ ) > >- There are no benchmarks, comparing to Java/Coldfusion/whatever. None of these give you anything like the hooks that mod_perl gives you, though, so in general they are uncomparable. CF is pig-slow, and java - well. :) > >- I work at a big telco, and no one cares/knows here about > > mod_perl (except our intranet-webmaster, who still prefers > > PHP, since it makes him less trouble). Again, not comparable. I have written a quick hack auth system that hooks into uri translation, try doing that under any other system. > >- People, who have heard about mod_perl, are looking for servlet/ > > JSP-programmers, because mod_perl-coders are hard to find. perhaps. Mod_perl jobs are hard to find too... :/ > I unfortunately have to agree. perhaps. > Depending on where you go Perl programmers may be easier to find that Java > programmers, but finding an existing mod_perl programmer is not easy. It's > doable, but not easy. And in the end, the salaries for mod_perl programmers > are pretty high right now because of it -- so will a system really cost > less to develop in mod_perl than in Java if Java programmers are becoming > less expensive than mod_perl programmers? I have yet to see companies in this country really advertising for mod_perl jobs. The company where I currently work mentions it, but we're not really looking for it very hard, and if they've done any perl, we mostly teach them about the templating system we use (yes, yet another one, and going on CPAN soon :) > We all have to do our part to evangelize mod_perl more. I think ISPs are > really key here as I think I may have mentioned before. If you get the ISPs Well, I can tell you for a fact that mod_perl is running on http://www.bluepet.co.uk/ http://www.freedomjewellery.com/ http://www.londontransport.co.uk/ http://www.swisslife.com/ http://www.sciencephoto.com/ (the current version uses PerlRun, but the new version will be all mod_perl) > supporting and evangelizing mod_perl (and pre-installed mod_perl > applications) then you will get users using it and liking it. How many ISPs Yes, but the way it runs does raise problems for security > advertise support for mod_perl? How many without charging like US$100 more > a month on top of the normal account fees? This is difficult, due to the security issues. If you have client cgi, you can always use something like suEXEC or even something as complex as userv to run your cgi scripts. With mod_perl, the plugged in scripts can do anything that the webserver can, and you can (by writing a module that doesn't compile) break the entire webserver. > PHP comes with a lot of ISP accounts for free with no extra cost. Java does > not yet, but I've started seeing ISPs starting to support Java in the low > end shared server accounts... Wow. I'm surprised, for the security reasons I've outlined above. But then I don't know much about PHP, really. MBM -- UNIX is hot. It's more than hot. It's steaming. It's quicksilver lightning with a laserbeam kicker. -- Michael Jay Tucker
Re: tracking down why a module was loaded?;
"One or two mod_perlers could do the work of a java shop of ten in half the time." Can we prove this ? Does anyone have any real evidence to support this claim. I hope so because I need to defend my use of mod_perl in developing the intranet site for my company ;-) All my experience suggests that this is true but sometimes the PHB's insist on the numbers. Simon. From ed <[EMAIL PROTECTED]>Date 26 September 2000 To Gunther Birznieks <[EMAIL PROTECTED]>Time 20:50 Copy to[EMAIL PROTECTED] (bcc: Simon Wilcox/BASE/WilliamsLea) Bcc Simon Wilcox/BASE/WilliamsLea Fax to Subject Re: tracking down why a module was loaded?; Gunther Birznieks wrote: > I unfortunately have to agree. > > And in the end, the salaries for mod_perl programmers > are pretty high right now because of it -- so will a system really cost > less to develop in mod_perl than in Java if Java programmers are becoming > less expensive than mod_perl programmers? > Mod_perl programmers are more expensive as individuals, because mod_perl is more powerful, and allows you access to the Apache API; mod_perlers are more saavy. One or two mod_perlers could do the work of a java shop of ten in half the time. Still a savings. Not to mention the hardware that goes with Java by fiat! ed __ This email contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or reply on this email.
