Re: $r->headers_out Location and Set-Cookie
On Fri, Sep 05, 2003 at 10:13:36, Geoffrey Young said... > actually, the return value is entirely ignored in Registry scripts - that's > why we need the $r->status hack, which is not needed (or desired) in > handlers. if you returned SERVER_ERROR it would still work, so long as you > set $r->status :) Oh! I totally missed that you're using Apache::Registry. I'm not sure the best way to do it with that, sorry. -- Michael Stella | Sr. Unix Engineer / Developer | http://www.thismetalsky.org "All I want out of the Universe is 10 minutes with the source code and a quick recompile." - unknown -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: $r->headers_out Location and Set-Cookie
On Wed, Sep 03, 2003 at 09:42:00, Garrett Goebel said...
>And gives the following recipe:
>
> Example A-3. redirect_cookie.pl
> use Apache::Constants qw(REDIRECT OK);
> my $r = shift;
> # prepare the cookie in $cookie
> $r->err_headers_out->add('Set-Cookie' => $cookie);
> $r->headers_out->set(Location => $location);
> $r->status(REDIRECT);
> $r->send_http_header;
> return OK;
>
>How would you have written it?
Seems to me you'd want to *return* REDIRECT, not set $r->status to REDIRECT.
Here's what I do in this case:
$r->header_out(Location => $location);
return REDIRECT;
I don't know if it's 100% correct, but it works quite well for me.
I've also used $r->internal_redirect($location) for some things, but I don't
think that's appropriate here.
--
Michael Stella | Sr. Unix Engineer / Developer | http://www.thismetalsky.org
"To dwell on the destination is to waste the journey"
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
using "-|" construct
I have a web service that need to get "stuff" from the system and is
using the following subroutine to retrieve info.
sub systeminfo {
if (open(FROMADMIN,"-|")) { # parent
undef local $/;
my $rv = ; # get response
close FROMADMIN;
return $rv;
}
else {
unless (open STDERR, '>&STDOUT') {
print STDERR "can't dup STDERR to STDOUT: $!";
exit 1;
}
my($command,$stdin) = @_;
open(ADMIN,'|'. $command);
print ADMIN $stdin
if $stdin;
close ADMIN;
exit 0;
}
}
This works fine for command line exection and from cgi but fails in
modperl (apache 1x).
The problem is that the initial read pipe apparently fails to open
under modperl.
Is there a workaround for this? or am I just missing something
simple?
Michael
[EMAIL PROTECTED]
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::DBI
It looks like your PostgreSQL installation is trying to do IDENT
authentication, instead of MD5. So, it's checking the user your script is
running as, and trusting that since you managed to log on with your
username/password already, it'll trust you to log into the database.
While this isn't strictly an Apache problem, but rather a database problem,
here's what's probably the matter. In your /var/lib/pgsql/data/pg_hba.conf
file, you probably have the default:
local all all trust
I would suggest changing this to something like:
local all all md5
or make it IP based:
host allall1.2.3.4255.255.255.255 md5
you get the idea. That way, it'll obey the username/password that you supply.
On Thursday 28 August 2003 04:28 pm, wrote:
> Hello, every body
>
> I can run the following subroutine in DBI, but Apache::DBI...
>
>
> use DBI;
>
> sub connect{
> $dbh = DBI->connect("dbi:Pg:dbname=test", "canis","3dsadasz");
>
> $sth = $dbh->prepare("SELECT clave, denominacion FROM Marca")
>
> || die $dbh->errstr;
>
> $sth->execute() || die $sth->errstr;
>
> while(my $row = $sth->fetch){
> my($clave, $nombre) = @$row;
> print "clave => $clave, denominacion => $nombre\n";
> }
> $dbh->disconnect;
> }
> and I have this log...
>
> [Thu Aug 28 12:36:44 2003] [error] (2)No such file or directory:
> mod_mime_magic: can't read magic file /etc/apache-perl/share/magic
> [Thu Aug 28 12:36:45 2003] [notice] Apache/1.3.26 (Unix) Debian GNU/Linux
> mod_perl/1.26 configured -- resuming normal operations
> [Thu Aug 28 12:36:45 2003] [notice] suEXEC mechanism enabled (wrapper:
> /usr/lib/apache/suexec)
> [Thu Aug 28 12:36:45 2003] [notice] Accept mutex: sysvsem (Default:
> sysvsem) [Thu Aug 28 12:37:03 2003] null: DBI->connect(dbname=test) failed:
> FATAL 1: IDENT authentication failed for user "canis" at
> /var/lib/perl/JCVA/Conexion.pm line 11
> [Thu Aug 28 12:37:03 2003] [error] Can't call method "prepare" on an
> undefined value at /var/lib/perl/JCVA/Conexion.pm line 13.
> Somedody knows if the user must be registered in some configuration file?
--
/* Michael A. Nachbaur <[EMAIL PROTECTED]>
* http://nachbaur.com/pgpkey.asc
*/
"Another world, another day, another dawn. "
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
On Wed, Aug 27, 2003 at 15:45:11, Charlie Garrison said... > >I haven't been 100% happy with any of the systems written by other > >people so I've always just written my own. It's a rather simple > > Do you also write the apache module for the frontend server? I'm very > competent at perl, but not competent enough to write an apache module. > > Any other suggestions? I'd think you'd want to have the same authentication process for both, and a shared database (or something) to store the session data. Have the front-end do the login part, pass the client to the backend, which discovers that the client is already authenticated. Are you looking for something that's just a drop-in solution, transparent to the backend completely, not part of the backend software? I'd think in that case, you'd want something like PerlAuthenHandler and PerlAuthzHandler, let them manage the logins and just pass the client down to the backend software. I could still be way off here though. -- Michael Stella | Sr. Unix Engineer / Developer | http://www.thismetalsky.org -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
On Wed, Aug 27, 2003 at 14:49:05, Cees Hek said... > It was easy to miss in the email if you skimmed it, but he is looking for a C > based module, so any perl based solutions are out. Whoops, you're right, I did just skim it. > The reason this question is mod_perl related is that he is doing the initial > authentication using mod_perl, and is creating a cookie based ticket. But he > wants that ticket to also be accepted by a non-mod_perl enabled server (ie a > front end proxy). So the database connection has to persist from the mod_perl authentication scheme to the backend software? Interesting... Does that work? -- Michael Stella | Sr. Unix Engineer / Developer | http://www.thismetalsky.org If Bill Gates had a nickel for every time Windows crashed... ..oh wait, he does. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
On Tue, Aug 26, 2003 at 21:06:05, Charlie Garrison said... > The second one, Cookie Authentication with MySQL, looks like a very good > option, except for two issues. Fist, it doesn't support the 'require group...' > directive. And second, it doesn't appear to cache mysql connections so I am > concerned about the increased load from lots of quick connections. Umm, use Apache::DBI, that's what it's for. > I feel that someone must have already solved this issue so any suggestions or > advice would be appreciated. Are there any modules which I have missed? Are > the perceived problems with the above modules really an issue, or should I be > able to use one of them without any problems. I haven't been 100% happy with any of the systems written by other people so I've always just written my own. It's a rather simple process. Right now I have one method that uses cookies in one module, another that uses cookies but splits things up into separate modules, and a third that adds a (md5 hash) parameter to the URI. All work very well, though I prefer the cookie method myself. If there's really nothing out there to add a hash to the URI, I could probably be convinced to package up the code I have, simple as it may be. -- Michael Stella | Sr. Unix Engineer / Developer | http://www.thismetalsky.org Knowledge is power. Power corrupts. Study hard. Be Evil. - Thyra -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mp2 on osx jaguar won't load mod_perl.so
On Saturday, August 16, 2003, at 05:16 pm, Stas Bekman wrote: Michael Chamberlain wrote: On Saturday, August 16, 2003, at 07:03 am, Douglas Theobald wrote: I've been quite successful with mp1 (Apache/1.3.28, mod_perl/1.28, perl 5.8.0, OSX jaguar 10.2.6.), but I'd really like to get mp2 going on OSX. Has anyone had any luck or experienced this same problem? Rebuild your perl with threads support, and only use '-lm -lc'. Michael, what's the deal with using only '-lm -lc' on jaguar? Care to send a patch so it'll work out of box? I'll double check if it's significant or not. I was having major problems getting stuff to build before you posted your link initially to that working config. The -lm -lc and threads bits where the only areas which where different. Changing to those everything worked. Mike. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mp2 on osx jaguar won't load mod_perl.so
On Saturday, August 16, 2003, at 07:03 am, Douglas Theobald wrote: I've been quite successful with mp1 (Apache/1.3.28, mod_perl/1.28, perl 5.8.0, OSX jaguar 10.2.6.), but I'd really like to get mp2 going on OSX. Has anyone had any luck or experienced this same problem? Rebuild your perl with threads support, and only use '-lm -lc'. All should work fine as a DSO then. Mike. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: [mp2] ModPerl::Test::read_post destructive?
Yikes, you're right! I just found a recent thread in the apache dev list discussing this. Thanks, I'll approach my problem another way. - Mike. -Original Message- From: Ged Haywood [mailto:[EMAIL PROTECTED] Sent: Sunday, August 10, 2003 12:47 PM To: Michael Maciag Cc: Modperl Mailing List Subject: Re: [mp2] ModPerl::Test::read_post destructive? Hi there, On Sun, 10 Aug 2003, Michael Maciag wrote: > Is the read_post in ModPerl::Test destructive in some way? If so, could > someone point me in the right direction I might take to modify it to be > non-destructive? I think you'll find that reading POST data has always been destructive. If you want to read it more than once you have to save it somewhere. Check the archives for more information. 73, Ged.
[mp2] ModPerl::Test::read_post destructive?
Apache/2.0.44 (Unix) mod_perl/1.99_09 Perl/v5.8.0 Using a copy of the read_post routine, I'm able to retrieve my POST parameters reliably from my PerlResponseHandler. However, it seems when I do invoke that routine, the client no longer receives the parameters. If I just comment out my invocation of read_post, the client once again receives the POST parameters. Is the read_post in ModPerl::Test destructive in some way? If so, could someone point me in the right direction I might take to modify it to be non-destructive? - Mike.
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Mon, Aug 04, 2003 at 11:19:42AM +0100, Steve Hay wrote: > Why isn't the typemap file distributed as part of ExtUtils-MakeMaker? typemap is very specific to the version of Perl, or so it is said. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ You're more radiant than a memory of breathtaking ecstasy.
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Mon, Aug 04, 2003 at 09:35:55AM +0100, Steve Hay wrote: > Somehow, it has contrived to disappear! It always used to exist there, > which is why it didn't occur to me to check :-( I must have lost it > somewhere along the line when shoe-horning earlier MakeMaker's into place. Possibly you deleted the ExtUtils/ directory? > Having now restored that file, the patch above does indeed fix it for me. Yay! -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ I need a SHOWER a BURGER and some ROBOTS, STAT! -- http://www.angryflower.com/allrigh.gif
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Mon, Aug 04, 2003 at 08:46:27AM +0100, Steve Hay wrote:
> I tried changing the s/// to:
>
>$string =~ s{ \$\(INST_DYNAMIC\)}{}g;
>$string =~ s{ \$\(INST_BOOT\)}{}g;
>
> (I've dropped the trailing spaces in the patterns), which produced:
>
> dynamic :: $(FIRST_MAKEFILE)
>$(NOECHO) $(NOOP)
>
> in the Makefile as desired, but now the build process fails with this error:
>
> fatal error U1073: don't know how to make 'C:\perl5\lib\ExtUtils\typemap'
That's odd. Does that file exist? If not, where is your typemap file?
--
Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/
I'm exploring my nipples.
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Fri, Aug 01, 2003 at 11:35:47AM +0100, Steve Hay wrote:
> =
> # --- MakeMaker dynamic section:
> ## $(INST_PM) has been moved to the all: target.
> ## It remains here for awhile to allow for old usage: "make dynamic"
> #dynamic :: Makefile
> dynamic :: Makefile
>@$(NOOP)
> =
>
> while the corresponding section from the 6.12 build contains this:
>
> =
> # --- MakeMaker dynamic section:
> ## $(INST_PM) has been moved to the all: target.
> ## It remains here for awhile to allow for old usage: "make dynamic"
> dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
>$(NOECHO) $(NOOP)
> =
>
> If that's relevant, then the latter looks more likely to be correct,
> doesn't it? Perhaps MM 6.06+ has correctly fixed a bug in MM 6.05, and
> the only problem here is that libapreq was previously relying on that bug?
The problem is likely the MY::dynamic hack in c/Makefile.PL. 6.05 and
previous had this:
dynamic :: Makefile $(INST_DYNAMIC) $(INST_BOOT)
6.06_01 and up have this
dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
for some reason, MY::dynamic is trying to lop off everything after "Makefile"
and moving $(INST_DYNAMIC) to a different target in MY::top_targets.
(Where INST_BOOT is run from, I dunno). But dynamic no longer matches
/Makefile/ so the hack fails and you wind up with INST_DYNAMIC built from
two places.
Coupled with the fact that its set LINKTYPE 'static' with a comment
"problems with things finding libareq.so, sort out later" leads me to
believe this was a work around a MakeMaker bug.
Chaning s/(Makefile\s+).*/$1/g to
s{ \$\(INST_DYNAMIC\) }{}g;
s{ \$\(INST_BOOT\) }{}g;
should "fix" the symptoms by restoring the hack for a quick fix.
For a longer term solution, try removing the MY::dynamic and
MY::top_targets overrides entirely, plus changing LINKTYPE to 'dynamic' and
see what happens.
It would be nice if someone could dig through libapreq's version history
and figure out when and why this hack was put in.
--
WOOHOO! I'm going to Disneyland!
http://www.goats.com/archive/980805.html
Apache::AuthCookie 3.05 prerelease
I have placed a pre-release of Apache::AuthCookie 3.05 which supports mod_perl version 2 (as well as mod_perl version 1) up on the sorceforge downloads. The API has changed slightly for mod_perl version 2 in order to avoid using Apache->request. See the README.modperl2 file in the distribution for the detailed changes. The API has not changed in the version of the module for mod_perl 1.x. Obviously since the API has changed, and because this is the first release supporting mod_perl v2, this is an alpha release. This release is targeted at developers of AuthCookie subclasses that wish to port their subclasses to mod_perl2. If I do not get complaints about the AuthCookie API changes that I have made, I will upload this release to CPAN. You can get AuthCookie 3.05pre1 from: https://sourceforge.net/project/showfiles.php?group_id=12701 Regards, Michael Schout GKG.NET, INC
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Fri, Aug 01, 2003 at 09:05:55AM +0100, Steve Hay wrote: > I just tried MM 6.13: that made no difference. > > Then I tried the snapshot (taken at 01 Aug 2003 07:55 UTC): that failed > loads of its own tests, but made no difference to the libapreq build > process. Oh yeah, I didn't update the snapshot. Thanks for the reminder. -- You can't control the universe with a jar of red pepper. http://www.goats.com/archive/981004.html
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Fri, Aug 01, 2003 at 10:03:20AM +0100, Steve Hay wrote:
> >This bug evidently goes back a long way: MM 6.06_02 fails in the same
> >way as 6.13.
> >
> >I tried to use MM 6.06_01, but it wouldn't build itself ("don't know
> >how to make 'C:\perl5\libNAME'"). Instead, I knife-and-forked it into
> >place, but when I tried to use it to build libapreq, I just got the
> >same error again - "don't know how to make 'C:\perl5\libNAME'".
>
> OK, I've got MM 6.06_01 building now (it was generating broken Makefiles
> -- needed to change DIRFILESEP from \ to ^\, and fill in the missing
> *PERLSAFE macros), and the bad news is that it doesn't build
> libapreq-1.2 either! I still get the "unresolved external symbol
> boot_libapreq" error.
>
> So it's one of the many changes between 6.05 and 6.06_01 that broke it.
Well, that narrows it down quite a bit.
Which version of mod_perl and Apache is this against and *exactly* what do
I have to do to exercise this bug? I haven't built mod_perl in a long time.
--
I'll tell you what beats voodoo every time, a big ass knife.
-- "Overkill" Battlebot driver
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Thu, Jul 31, 2003 at 01:27:01PM -0700, Michael G Schwern wrote: > I'm glad you guys got it working, but there's still the problem of why > MakeMaker's behavior changed. Since I tend not to touch the XS building > code much its likely a bug. Try the snapshot on makemaker.org. I just > fixed a minor issue with argument passing in recursive builds. Actually, try 6.13. That snapshot had a bug in it. -- Abandon failing tactics.
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Thu, Jul 31, 2003 at 03:23:36PM +0100, Steve Hay wrote: > This patch finally fixes it for me: I'm glad you guys got it working, but there's still the problem of why MakeMaker's behavior changed. Since I tend not to touch the XS building code much its likely a bug. Try the snapshot on makemaker.org. I just fixed a minor issue with argument passing in recursive builds. If I could see the Makefiles from 6.03 and 6.12 I might be able to figure out what's different. Also, if you could try various alpha versions between those two, show the Makefiles and whether or not they exhibited the behavior that would help alot in narrowing it down. -- You're the sickest teenager I've ever set my wallet on.
Re: privileged execution
> Mike P. Mikhailov wrote: > > Hello Michael, > > > > Wednesday, July 30, 2003, 7:32:23 AM, you wrote: > > > > M> I have a web application for that needs to execute a privileged > > M> command on its host for administrative purposes. Can someone suggest a > > M> good solution that will allow 'nobody' to execute the script command > > M> but still keep it secure from other users on the same host. > > > > M> Thanks. > > M> [EMAIL PROTECTED] > > > > You may start internal separate process with priveleges as required > > for your tasks and talk with him from apache unpriveleged process to > > do privileged job. > > That and Lincoln Stein wrote a tpj article: "Safely Empowering Your CGI > Scripts" back in Summer 1998: > http://www.foo.be/docs/tpj/issues/vol3_2/tpj0302-0006.html > Of course you will probably want to use a more modern library to do the job, > e.g. IPC::Run. > Thanks guys. Michael [EMAIL PROTECTED]
privileged execution
I have a web application for that needs to execute a privileged command on its host for administrative purposes. Can someone suggest a good solution that will allow 'nobody' to execute the script command but still keep it secure from other users on the same host. Thanks. [EMAIL PROTECTED]
http responses piped to STDERR
I'm (very) occasionally seeing the output of Apache::Registry scripts sent to STDERR instead of STDOUT. That is, the entire http response (headers included) appears in my error log, while nothing at all is displayed to the client. Could someone kick me towards what I should look into here? thanks, michael
Apache::DBI and temporary tables
Hello all, I know from a DBI perspective, when using PostgreSQL, if I create a temporary database table it will automatically go *poof* and be deleted when the database connection is closed (or when the transaction is finished...I can't remember which). Anyway, what will happen if code that takes advantage of this is used in an Apache Registry script? If I do a $dbh->disconnect, I know it will be ignored by Apache::DBI, but is it smart enough to pass something back to the database server telling it that it can purge temporary data? Thanks. -- /* Michael A. Nachbaur <[EMAIL PROTECTED]> * http://nachbaur.com/pgpkey.asc */ `This must be Thursday,' said Arthur to himself, sinking low over his beer, `I never could get the hang of Thursdays.'
Re: If (!$one_thing) {$other;}
Here is a little script I wrote a while back so that I could look at headers
being sent from my server in a browser window.
JM.
- Original Message -
From: "Dennis Stout" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 02, 2003 4:44 PM
Subject: If (!$one_thing) {$other;}
> This is irking me.
>
> $state preserves information about the request and so on. Now,
> $r->whatever_method works just fine.. EXCEPT for sending headers. When I
> visit my site, I get my nifty login page, and that is all. Always the
login
> page.
>
> I telnetted into the thing to see what kinds of cookie strings I was
getting
> back and... NO HEADERS! No Content-type: 's or nothing.
>
> $r->send_http_header; must be broken, eh? How to fix?? =P
>
> I'll spare all of your eyes by not sending complete source, but here's the
> basic idea.
>
>
> #!/usr/bin/perl
>
> package RequestHandler;
> use strict;
>
> # snipped out a lot of use vars qw();'s and $val = blah.
>
> sub handler {
> my $r = shift;
> my $result = undef;
>
> eval { $result = inner_handler($r) };
> return $result unless $@;
>
> warn "Uncaught Exception: $@";
>
> return SERVER_ERROR;
> }
>
> sub inner_handler {
> my $r = shift;
>
> my %q = ($r->args, $r->content);
> my %state = (r => $r, q => \%q);
>
> $state{login_user} = '';
> $state{login_pass} = '';
> $state{title} = '';
> $state{template} = '';
> $state{auth_status} = password_boxes(\%state);
>
> validate_auth_cookie(\%state);
>
> my $function = $r->uri;
> $function = '/login.html' if $state{login_user} eq '';
> my $func = $Dispatch{$function} || $Dispatch{DEFAULT};
>
> return $func->(\%state);
> }
>
> sub output_html {
> my $state = shift;
> my %args = @_;
> my $title = $state->{title};
> my $r = $state->{r};
>
> $r->status(200);
>
> my $template = HTML::Template->new(
> filename=>
> "$Template_Dir/$state->{template}",
> die_on_bad_params => 0,
> );
>
> $template->param(TITLE => $title);
> eval { foreach (keys %args) {
> $template->param($_ => $args{$_});
> }};
> $template->param(ERRORS => $@) if $@;
>
> $r->header_out( 'Set-Cookie' => $state->{cookie_out} ) if
> $state->{cookie_out};
> $r->send_http_header('text/html');
> print $template->output();
> }
>
> sub get_password {
> my $state = shift;
>
> my $row = $Sql->select_hashref('DECODE(PWORD,\'blah\')', 'techs',
> "TECH=\"$state->{
> q}->{login_user}\"");
> return $row->{"DECODE(PWORD,'blah')"};
> }
>
> sub build_auth_string {
> my $state = shift;
> my $ip = shift || $ENV{REMOTE_ADDR};
> my $time = shift || time;
>
> my $login = $state->{login_user};
> my $password = $state->{login_pass};
> my $val = join "::", $login, $ip, $password, $time;
>
> # Iterate thru by 8 byte hunks.
> # with the added 8 spaces, do not do the last hunk
> # which will be all spaces
> my $blown;
> my $pos;
> for ( $pos = 0; (($pos + 8) < length($val) ) ; $pos+=8 ) {
> $blown .= $cipher->encrypt(substr($val, $pos, 8));
> # encrypt this without temp vars
> }
>
> my $enc = encode_base64($blown,"");
>
> $enc;
> }
>
> sub parse_auth_string {
> my $state = shift;
> my $cookie = shift;
>
> return unless $cookie;
> return if $cookie =~ /logged_out/;
>
> my $unenc= decode_base64($cookie);
> my $unblown;
>
> # start at 8, take 8 bytes at a time
> # $unenc should be exactly a multiple of 8 bytes.
>
> my $pos;
> for ( $pos = 0; $pos $unblown .= $cipher->decrypt(substr($unenc, $pos, 8));
> }
> my ($login, $ip, $password, $time)=split ( /::/, $unblown, 4);
> }
>
> sub get_auth_cookie {
> my $state=shift;
> my $cookie =
TTMSCGI->parse_cookie($ENV{HTTP_COOKIE})->{ttms_user};
> my($login, $ip, $password, $time) = parse_auth_string($state,
> $cookie);
> ($login, $ip, $password, $time);
> }
>
> sub set_auth_cookie {
> my $state = shift;
>
> my $val = build_auth_string($state);
> my $c = TTMSCGI->build_cookie(
> name=> 'ttms_user',
> value => $val,
> expires => time + 86400*30*7,
> domain => $Cookie_Domain,
> path=> '/',
> );
> $state->{cookie_out} = $c;
> }
>
> sub build_logout_cookie {
> TTMSCGI->build_cookie(
> name => 'ttms_user',
> value => "logged_out",
> expires=> time - 86400,
> domain => $Cookie_Domain,
> path
[mp2] Building modperl2 on mac os x?
Hi Has anyone had any success in getting modperl2 to work on mac os x? make test cd "src/modules/perl" && make -f Makefile.modperl make[1]: Nothing to be done for `all'. /usr/bin/perl -Iblib/arch/Apache2 -Iblib/lib/Apache2 \ t/TEST -clean *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -clean APACHE_USER= APACHE_GROUP= APACHE_PORT= APACHE= APXS= \ /usr/bin/perl -Iblib/arch/Apache2 -Iblib/lib/Apache2 \ t/TEST -verbose=0 *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -verbose=0 /usr/local/apache2/bin/httpd -d /Users/mach/src/mod_perl-1.99_09/t -f /Users/mach/src/mod_perl-1.99_09/t/conf/httpd.conf -DAPACHE2 using Apache/2.0.45 (prefork MPM) waiting for server to start: ...[Sat Jun 28 12:36:19 2003] [info] 19 Apache:: modules loaded [Sat Jun 28 12:36:19 2003] [info] 3 APR:: modules loaded [Sat Jun 28 12:36:20 2003] [info] base server + 8 vhosts ready to run tests waiting for server to start: giving up after 61 secs !!! server failed to start! (please examine t/logs/error_log) make: *** [run_tests] Error 1 ** Date/Time: 2003-06-28 12:36:27 +0100 OS Version: 10.2.6 (Build 6L60) Host: imac.local. Command:httpd PID:3012 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x3b0a2020 Thread 0 Crashed: #0 0x0073b944 in Perl_hv_store_flags #1 0x006eb2d0 in Perl_gv_fetchpv #2 0x00715bb0 in Perl_newATTRSUB #3 0x0070ae3c in Perl_yyparse #4 0x00771f1c in S_doeval #5 0x00773520 in Perl_pp_require #6 0x00741978 in Perl_runops_standard #7 0x006e58e0 in Perl_call_sv #8 0x006e9418 in S_call_list_body #9 0x006e8f9c in Perl_call_list #10 0x00716f88 in Perl_newATTRSUB #11 0x00711e2c in Perl_utilize #12 0x0070afd0 in Perl_yyparse #13 0x00771f1c in S_doeval #14 0x00773520 in Perl_pp_require #15 0x00741978 in Perl_runops_standard #16 0x006e58e0 in Perl_call_sv #17 0x006e9418 in S_call_list_body #18 0x006e8f9c in Perl_call_list #19 0x00716f88 in Perl_newATTRSUB #20 0x00711e2c in Perl_utilize #21 0x0070afd0 in Perl_yyparse #22 0x00771f1c in S_doeval #23 0x00773520 in Perl_pp_require #24 0x00741978 in Perl_runops_standard #25 0x006e58e0 in Perl_call_sv #26 0x006e9418 in S_call_list_body #27 0x006e8f9c in Perl_call_list #28 0x00716f88 in Perl_newATTRSUB #29 0x00711e2c in Perl_utilize #30 0x0070afd0 in Perl_yyparse #31 0x00771f1c in S_doeval #32 0x00773520 in Perl_pp_require #33 0x00741978 in Perl_runops_standard #34 0x006e5dfc in Perl_eval_sv #35 0x006e613c in Perl_require_pv #36 0x003bca1c in modperl_require_file #37 0x003b89fc in modperl_config_apply_PerlRequire #38 0x003b6864 in modperl_startup #39 0x003b6eb8 in modperl_hook_init #40 0x003b9bbc in modperl_cmd_load_module #41 0x00035504 in invoke_cmd (config.c:828) #42 0x00035bc4 in ap_walk_config_sub (config.c:1083) #43 0x00035c64 in ap_walk_config (config.c:1122) #44 0x000367d8 in ap_process_config_tree (config.c:1595) #45 0x00023478 in main (main.c:639) #46 0x2034 in _start (crt.c:267) #47 0x1eb4 in start PPC Thread State: srr0: 0x0073b944 srr1: 0x0200f030vrsave: 0x xer: 0x lr: 0x0073b528 ctr: 0x0074ffb4 mq: 0x r0: 0x r1: 0xbfffc610 r2: 0x007d1560 r3: 0x r4: 0x00d15950 r5: 0x000e r6: 0x00d140b0 r7: 0x0908d3ab r8: 0x002c r9: 0x r10: 0x000f r11: 0x00d0e4d0 r12: 0x3b0a2020 r13: 0x007ca294 r14: 0x006e r15: 0x007ca294 r16: 0x00d140b0 r17: 0x007d166c r18: 0x3ff0 r19: 0x200b r20: 0x00d15950 r21: 0x00d14b0c r22: 0x r23: 0x000e r24: 0x r25: 0x00d0b2c8 r26: 0x22442244 r27: 0x003f4ad0 r28: 0x0908d3ab r29: 0x007cb528 r30: 0x3b0a2020 r31: 0x0073b528 Mike.
[mp2] Having trouble setting params with CGI
I'm trying to use CGI to get/set params within my mp2 PerlResponseHandler, at least until Apache::Request for mp2 is released. The get works just fine but my clients don't see the params I'm trying to set. Is it likely I just have an error somewhere or is there anything I have to do differently than just a simple: $q->param( -name => 'myparam', -value =>'myvalue') in my handler? - Mike
Re: Authentication design
Hmm, I see now. I don't really care about users who aren't logged in, so I don't know that there is a need to store session data for them. I guess my pattern is: within PerlAuthenHandler -Check to see if there are passed user/password params. If so, validate params against user/pass in database. If the params are valid, create a new session key, store the session key in the database, and set a cookie with the user_id and session_key. Isn't the session key unique? Why put both in the cookie? Because my session table is indexed off the user_id. I know that it probably won't matter until I have something like 100+ nearly-simultaneous users, but I thought that it would be nice to plan ahead, just in case. I guess what I am hearing is the good-ole Perl adage: tmtowtdi. I think that what I have both works and seems to fit my needs just fine, so I will stick with it, just wanted to make sure that it wasn't glaringly horrible for some reason. Thanks to all who chimed in. -Mike
Re: Installing Apache::AuthCookie
On Tue, 10 Jun 2003, Jay Strauss wrote: > I'm running into a problem during the make test while installing the current > version of Apache::AuthCookie. I'm not sure where to go. I looked at tests > 10 and 15: Hrm. You are supposed to get "ok" for all of the tests. If I had to guess from this I would say that there is something in your httpd.conf (that Apache::test is pulling the config from) that is screwing up the tests. Can you send me your t/httpd.conf? (privately, no need to send it to the list). Regards Michael -- Hal 9000 - "Put down those Windows disks Dave Dave? DAVE!!"
Re: Authentication design
Perrin Harkins wrote: Well, I'm not sure what's involved in determining $r->user aside from reading the cookie. It may not make any difference. Here's a typical pattern for this: - Fetch the session key from the validated cookie. - Load the session using that key. - Grab the user ID from the session. - Load the user's data based on that ID. The session stuff could be done in a separate phase before the content handler, or it could be done on demand when your script calls some utility method that knows how to get the current session. Same with the user. Not sure that I quite understand ... what do you mean by "load" the session/user data if it is being done in a handler before content phase? What would you use to store the retrieved data ... pnotes? Also, I am not quite sure of the distinction between session data and user data. Wouldn't session data be intrinsically tied to a user? My session table currently looks like [user_id, session_key, session_data, login_time, last_access_time]. I guess I am currently using the session table to be more of an authentication table, i.e. if you give me a good user_id/session_key ticket that matches what is in the database. I guess my pattern is: within PerlAuthenHandler -Check to see if there are passed user/password params. If so, validate params against user/pass in database. If the params are valid, create a new session key, store the session key in the database, and set a cookie with the user_id and session_key. -Otherwise, if there is a cookie, validate the cookie's user_id/session against the database one stored in the database. -If either the params or cookie passed muster, set $r->user and return Apache::OK. If the user passed incorrect parameters, redirect to a custom_error form which is the login page. Otherwise, return Apache::OK and do not set $r->user. within registry scripts: -If $r->user is set, turn on custom pages and load user preferences. -Mike
Re: Authentication design
Perrin Harkins wrote: I'm not certain it won't work to use $r->user, but I don't see the point when you already have a unique identifier in the cookie. Well, I figured that the AuthenHandler already parsed the authentication cookie and declared it valid, so I didn't really see a point the in doing it at the beginning of every script. $r->user just seemed more intuitive to me. -Mike
Re: Authentication design
Jonathan Gardner wrote: It sounds like you are mixing HTTP-level authentication with application-level authentication. Well, sorta. I am actually using a custom module very similar to the one found in the cookbook (and AuthCookie, I think), i.e. create a PerlAuthenHandler that sets the custom error message to the login page and redirects you to it if you pass it an incorrect user/password request. If it the user/pass checks out, I set a session cookie (md5 sum of stuff), store the session_key in the database (Postgres), and set $r->user. If no user/password or cookie is presented, I just return OK for most of the site. A couple of scripts are "login-only", and those are protected by an authz handler that makes sure $r->user is set. Everything is handled with my custom login forms, none of the crappy pop-ups for basic or digest authentication. So I guess that I am usurping the normal HTTP-authentication phase for my own nefarious purposes. I thought that this was a good way to go since I could protect my entire application with a single module and a couple lines in the config file, as opposed to bundling that authentication code into the beginning of *every* registry script that I write. And, from lurking on the board for a long time, I got the feeling that this is how everyone is doing it is that a correct assumption? -Mike
CGI.pm not processing POST within AuthenHandler
For some reason, CGI.pm (2.93) does not seem to parse POST data within a
PerlAuthenHandler. For example, the following:
sub handler {
my $r = shift;
my $q = new CGI($r);
my @params = $q->param;
$r->server->log->error("handler params are " . join "::", @params);
return Apache::OK;
}
logs the paramter names correctly if the request is a GET, but not if a
POST. The same code works fine within an Apache::Registry script, which
I assume will have the same behavior as a PerlResponseHandler. I also
attempted both the x-www-form-urlencoded and multipart/form-data POST
types and neither worked.
Am I missing something that mod_perl is not doing till the response
phase, like setting up STDIN? I thought that this might have had
something to do with an earlier thread
(http://marc.theaimsgroup.com/?t=10499295465&r=1&w=2), however I
also tried adding:
$r->subprocess_env;
Apache->request($r);
to the handler to no avail.
Thanks
-Mike
Apache/2.0.44 (Gentoo/Linux) mod_perl/1.99_09 Perl/v5.8.0 CGI.pm/2.93
AllowOverride None
Options +ExecCGI
SetHandler perl-script
PerlAuthenHandler Apache::MyAuth::handler
AuthType Cookie
AuthName MyPrivateStuff
require valid-user
PerlResponseHandler ModPerl::Registry
RE: DirectoryIndex doesn't see SetHandler path
Mark, I think that I may be able to clarify this. I ran into the same type of problem a few weeks ago. I had always defined my handlers inside a "Location" block and couldn't get the DirectoryIndex to work properly. I solved my problem by calling my handler from within a "Directory" block instead. You should be able to find the answer you're looking for on the following page. http://httpd.apache.org/docs/sections.html -Mike > -Original Message- > From: Marc M. Adkins [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 05, 2003 11:36 PM > To: [EMAIL PROTECTED] > Subject: DirectoryIndex doesn't see SetHandler path > > > This is going to seem odd...obscure...dumb... > > I've been using code like this to set up handlers: > > > SetHandler perl-script > PerlResponseHandler Some::Handler > > > Now I'm using this code to set up handlers for individual pages. The > directive above is in a sense telling Apache "there is a directory > /some/path/index which contains files which should be processed via > Some::Handler" but in fact there is no such directory. There is just a > handler. So in my mind I'm defining a single page with a handler. > > All this works OK, weird though it may be, until I want a directory index. > Say I want to go to url: > > /some/path > > The DirectoryIndex directive doesn't allow me to say that 'index' is a > directory, only 'index.html'. That is to say, the following: > > DirectoryIndex index index.html > > doesn't cause Apache to automatically find /some/path/index, even > if I have > defined one using AddHandler. I'm assuming this is because there > is no such > file, the handler is attached to the /some/path/index directory, > there isn't > anything for Apache to find. > > For the moment I'm faking things out using the miracle of mod_rewrite: > > RedirectMatch ^/some/path/index\.html /some/path/index > > which makes it all work like I want. NOW Apache finds the > handler for some > reason. So I'm not complaining, and I don't need a fix, but I > wonder if I'm > missing something. > > * AddHandler attaches a handler to a set of files with a given suffix. > * SetHandler attaches a handler to a location (a directory, right?) > and all of the files therein. > * There isn't (?) a directive that attaches a handler to a single leaf > in the directory tree which may in fact be non-existent in such a > manner that the DirectoryIndex directive will find the leaf. > > Have I missed something? Am I abusing the tool? > > mma > >
Authentication design
I am trying to design/implement a fairly simple authentication scheme using cookies and such, but wanted to air my design questions before I run into too many issues. I would like the site to be almost entirely publicly accessible, however if you log in you get special options in addition to the normal ones. Also, there are certain things that you can only do while logged in, like post comments. I figure that this is pretty standard. I currently have a PerlAuthenHandler that simply sets the $r->user if either the correct cookie was given or the correct user/pass parameters were passed (remarkably like the cookie authentication listed in the cookbook). It return Apache::OK on all cases except when the user/password parameters are invalid, in which case it redirects the user to the login page. I plan on using the $r->user as a test within my Apache::Registry scripts to see whether the user has successfully logged in and to display the options accordingly. My question basically centers around the best way to protect the "only if you login" pages. I was thinking of putting them in their own directory and protecting them with a tiny PerlAuthzHandler, which would scatter scripts of the same nature in two separate places (i.e. for comments, view->create->post), or protect the entire site with a PerlAuthzHandler that has a table of all of the "only if you login" pages, which has the drawback of having to change the handler every time I add a new script. Are there any other/better ways to do this? Thanks -Mike
htaccess files
Is it possible to configure an htaccess file to
call a script using apache registry and use it in the
PerlAccessHandler.
I have written one pretty large perl script in
mod-perl using the apache registry to serve out picture gallery pages. I
would like to do some validation of my own on a per directory type
basis.
also
I was trying to run this code to do some test and
could only get it to work with the #pound signs in from of the files
directives.
It works like this.
#
PerlAccessHandler 'sub {return Apache::Constants::FORBIDDEN;}' \
#
but I get this error in the log file. I could not get
it to work any other way.
[Fri May 30 00:22:52 2003] [warn] Apache does not support line-end comments.
Consider using quotes around argument: "#"
Thanks in advance
John Michael
Re: [mp1] .htaccess and mod_perl
Apache::StatINC is R.I.P. Use Apache::Reload instead. but Apache::StatINC comes with mp1 and Apache::Reload doesn't - it's difficult to install modules on these ensim boxes since you don't have root (and yes, there are other ways around it of course :) Well, Apache::StatINC wasn't distributed with the install of mod_perl that I was using (1.24) or else it wasn't in the global @INC, so I just snapped up the source from cpan and put it (with an addition to @INC) locally in my ensim tree. I will try and get Apache::Reload working, since Stas says so :) I think that I can install any module that doesn't need a compiler, although the whole 'make test' thing might get me since I don't have access to the httpd binary. Who needs testing anyway? Thanks -Mike
[mp1] .htaccess and mod_perl
I am stuck in an Ensim environment (shared web-hosting, Apache 1.3.27 and mod_perl 1.24) and am trying to get around some of the limitations imposed by Ensim. Basically, I have complete .htaccess control but have no way to restart the server or start it with different arguments or modify the central httpd.conf What is possible within an .htaccess file as far as perl configuration for mod_perl 1? I am already using the sections to unshift @INC (because 'PerlSetVar PERL5LIB /my/path' pushes the values) and have tried using PerlRequire startup.pl, however the startup.pl file only executes for one of the httpd children. What happens with PerlModule directives, i.e. does the module get loaded only once, the first time that apache processes the .htaccess, or every time apache hits the directory? Similarly, If I am developing a module in place and PerlModule it within an .htaccess, will it be reloaded whenever apache hits the directory, or only once? If its only once, can I force a reload of the module? Finally, can I use the sections to totally replace a startup.pl, or are there any caveats that I should be aware of? Thanks -Mike
[mp2] Authentication/Authorization modules
I am fairly new to mod_perl/apache, having grown up with OpenACS and AOLServer. I have read all of the docs on the web site (I think) and had a whole authentication/authorization scheme planned out using Apache::AuthCookie and Apache::Session. I was just put in charge of a beta web application (database backed, user preferences, etc), and would like to use Apache2/mp2 for it. I came to find that AuthCookie doesn't seem to be ported to mp2, so my origianal authorization plan went up in shambles, not to mention all of the other stuff that I have read (eagle book, developer's cookbook) seems to be centered around mp1 and libapreq. My newbie question is then, "what would the best way to implement an authorization scheme in mp2" and "are there any helpful modules ported"? I am thinking of something pretty standard, like what Apache::AuthCookie provides with a DB backend verifying the user/pass. I attempted to implement something like recipe 13.7 (from the cookbook) using CGI::Cookie instead of Apache::Cookie, but CGI complained about not being able to find Apache.pm. I assume that I just need a newer version (using stock RH8.0 with new apache and mod_perl). Any help would be appreciated. Thanks -Mike
Re: Convert Cookies-->HTTP Request Headers?
>On Fri, Apr 04, 2003 at 04:10:03PM -0500, Kruse, Matt wrote: >> I have a unique need purely for testing purposes. I'm not very familiar >> (yet) with mod_perl handlers in Apache, so I've had a rough time >>getting >> anything going. >> Here is my goal: >> >> For every request to Apache: >> 1. Parse the cookie coming in via the request header >> 2. Pull out each value (ex: NAME=bob;TITLE=boss) >> 3. Convert them to HTTP Request Headers >> >Ok, I'm confused: the cookies are already in the request header, >and you want to 'convert' them into a request header? > > 4. Pass the request on to the requested resource (a script of some >sort) > >> So, if I have a cookie like: NAME=bob;TITLE=boss >> My program would then see the following headers in the request: >> HTTP_NAME=bob >> HTTP_TITLE=boss >If you're using an Apache handler, see Apache::Cookie for unpeeling >cookies. >If you're running a classic CGI program, see CGI::Cookie for unpeeling >cookies. >> This will help me simulate a Single-Sign-On situation where the >> authentication handler passes all authenticated user information to the >> resource via headers. > >When you say 'HTTP request headers', did you really mean to say 'CGI >parameters', as the CGI module uses the term? > >> Thanks! >> >> Matt Kruse Also see: Apache::FakeCookie on CPAN for testing cookies without having to load httpd. It replaces the httpd server for generating cookie responses during development and testing of Apache-perl modules Michael
Off Topic but curious
If I bought a domain name with perl in it to build a perl script site, would I be infringing on any perl trademark or copyrights. Would it be ok or could I be told I couldn't use the domain. Thanks John Michael
Re: Server questions
I am not familiar with clustering Would you run a mod_perl based web site on a cluster? Isn't the point of a cluster to make a group of machines appear to be one? If so, how is that beneficial for web services? Thanks...Michael - Original Message - From: "Dzuy Nguyen" <[EMAIL PROTECTED]> To: "Modperl" <[EMAIL PROTECTED]> Sent: Friday, March 07, 2003 6:19 PM Subject: Re: Server questions > I always say, buy the best you can afford. > Then again, consider how many Linux PC you can have for the price of the Sun. > Run those PCs in a web farm or cluster and that Sun can't match the processing > power and speed. > > Michael Hyman wrote: > > Hi guys, > > > > I have a dilemma that I need input on. > > > > If you were to buy machines to be used as dedicated web servers, which would > > you go with? > > > > Option 1. A Sun SunFire 280R with 2 Ultra 3 processors and 4GB RAM. Run > > Solaris 9 > > > > Option 2. PC-server with 2 ~2.8GHZ Xeon processors and 8GB RAM. Run Linux > > > > The prices are worlds apart and I think I will get more bang for the buck > > with PC. > > > > The systems will connect to an Oracle server, via SQL*Net and server both > > dynamic and static content along with providing download files up to 1GB in > > size. The files will be stored locally. > > > > What I want to understand is which machine will be faster, be able to handle > > more peak loading, have a longer lifespan yet be upgradeable for a > > reasonable price. > > > > In the benchmarking we have done, we run out of Ram before CPU using Apache > > 1.3.27 and Mod_perl, so we will heavily load the machines with RAM. > > > > I have years of experience with Solaris and SunOS, and little with Linux, > > but the learning curve seems small and easily handled. It seems to me that > > Linux is more customizable than Solaris, but then Solaris comes pretty well > > tuned and does not always need much tweaking. > > > > Apache and all of our software components support both Solaris and Linux, so > > we can go either way as far as that goes. > > > > I think it comes down to a simple formula of which option gets us the most > > peak and sustained performance for the least amount of money. > > > > So, I am looking for some input as to which way you might go in my > > positions. > > > > Thanks in advance for the help!! > > > > Regards...Michael > > > > > > > > > > >
Server questions
Hi guys, I have a dilemma that I need input on. If you were to buy machines to be used as dedicated web servers, which would you go with? Option 1. A Sun SunFire 280R with 2 Ultra 3 processors and 4GB RAM. Run Solaris 9 Option 2. PC-server with 2 ~2.8GHZ Xeon processors and 8GB RAM. Run Linux The prices are worlds apart and I think I will get more bang for the buck with PC. The systems will connect to an Oracle server, via SQL*Net and server both dynamic and static content along with providing download files up to 1GB in size. The files will be stored locally. What I want to understand is which machine will be faster, be able to handle more peak loading, have a longer lifespan yet be upgradeable for a reasonable price. In the benchmarking we have done, we run out of Ram before CPU using Apache 1.3.27 and Mod_perl, so we will heavily load the machines with RAM. I have years of experience with Solaris and SunOS, and little with Linux, but the learning curve seems small and easily handled. It seems to me that Linux is more customizable than Solaris, but then Solaris comes pretty well tuned and does not always need much tweaking. Apache and all of our software components support both Solaris and Linux, so we can go either way as far as that goes. I think it comes down to a simple formula of which option gets us the most peak and sustained performance for the least amount of money. So, I am looking for some input as to which way you might go in my positions. Thanks in advance for the help!! Regards...Michael
mod_perl 1.27 intermittent Segmentation Faults
I am getting sporadic segmentation faults with mod_perl 1.27. A look at the core dump always shows: - lwp# 1 / thread# 1 0008b37c mod_perl_sent_header (360fc0, 997ec, 599394, 326c00, 0, 0) + 18 00241c14 Perl_pp_entersub (31c800, 4a3d60, 4, 1, 0, ff00) + 568 00239dc8 Perl_runops_standard (326c00, 1a, c0, 328c00, 37fd08, 59bba0) + 30 001e8928 S_call_body (ffbef078, 0, 326c00, 40, 81010100, ff00) + 5c 001e8398 Perl_call_sv (599394, 4d2cd4, 18, 392ed0, 326c00, 557178) + 250 001e8138 Perl_call_method (2e9790, 0, 0, 329000, 64, 4d2cd4) + 18 0023b720 Perl_pp_print (4d2cd0, 0, 4d2cd0, 1, 4d2cdc, 4d2cd8) + 1cc 00239dc8 Perl_runops_standard (326c00, 326c00, ffbef2dc, 1, 0, 5af328) + 30 001e8928 S_call_body (ffbef358, 0, 326400, 35e598, 326c00, ff00) + 5c 001e8624 Perl_call_sv (0, 4d2cd0, 326c00, 2b6580, 0, 2d) + 4dc 0008d760 perl_call_handler (3b73dc, 55cea8, 0, 2b6538, 0, ff00) + 5bc 0008cf4c perl_run_stacked_handlers (2b5b30, 55cea8, 38a384, 0, 0, 425078) + 1d0 0008c1bc perl_access (55cea8, 8c0f4, 323684, f72cc, 0, 424c98) + c8 000f2c00 run_method (55cea8, 1b, 1, 0, 2f575354, 2f636769) + 88 000f2cf0 ap_check_access (55cea8, 2cdf70, 2cdc00, 2cc1c1, 45, 65) + 1c 00112750 process_request_internal (55cea8, 0, 2c0, 0, ec00, 1) + 2dc 00112be0 ap_process_request (55cea8, c8, 55cea8, ffbef738, ffbef748, 0) + 3c 00105674 child_main (0, 1034c4, 103400, ff13b1e0, ff135910, ff12efc0) + 978 00105a28 make_child (32b378, 0, 3e4282ab, 0, 10, ff02b404) + 1a4 00105b4c startup_children (1, 0, 1, 307000, 6c6f6700, 6c6f6700) + b4 00106580 standalone_main (2, ffbef9fc, 0, 0, ff23b01c, 2cbb68) + 2fc 001071f4 main (2, ffbef9fc, ffbefa08, 326464, 0, 0) + 548 0004599c _start (0, 0, 0, 0, 0, 0) + 5c So, it is always happening at the 'mod_perl_sent_header'. Sometimes it can take hours before a segmention fault occurs. Sometimes it is immediate. Every time I get the core dump, the location is the same--mod_perl_sent_header. Any information would be very helpful. ---Mike Configuration info follows: --- Environment information: SunOS Solaris 8 === apache error_log: = [Thu Feb 6 10:43:39 2003] [notice] Apache/1.3.27 (Unix) mod_perl/1.27 mod_fastcgi/2.2.12 mod_ssl/2.8.12 OpenSSL/0.9.6g configured -- resuming normal operations [Thu Feb 6 10:45:11 2003] [notice] child pid 1935 exit signal Segmentation Fault (11), possible coredump in /opt/wstr/apache mod_perl 1.27 = perl -V === Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=solaris, osvers=2.8, archname=sun4-solaris uname='sunos caesun12 5.8 generic_108528-13 sun4u sparc sunw,ultraax-i2 ' config_args='-de -Dcc=gcc -Dprefix=/opt/wstr/perl -Dstartperl =#\!/usr/bin/env perl -Alibs=-lsocket -lnsl -ldl -lm -lc -lcrypt -lsec -lthread' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O', cppflags='-fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.95.3 20010315 (release)', gccosandvers ='solaris2.8' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib ' libpth=/usr/local/lib /usr/lib /usr/ccs/lib libs= -lsocket -lnsl -ldl -lm -lc -lcrypt -lsec -lthread perllibs=-lsocket -lnsl -ldl -lm -lc -lcrypt -lsec -lthread libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under solaris Compiled at Dec 9 2002 17:57:24 @INC: /opt/wstr/perl/lib/5.8.0/sun4-solaris /opt/wstr/perl/lib/5.8.0 /opt/wstr/perl/lib/site_perl/5.8.0/sun4-solaris /opt/wstr/perl/lib/site_perl/5.8.0 /opt/wstr/perl/lib/site_perl Apache version 1.3.27 mod_perl built with: /opt/wstr/perl/bin/perl Makefile.PL \ APACHE_SRC=../apache_1.3.27/src \ DO_HTTPD=1 \ USE_APACI=1 \ PREP_HTTPD=1 \ EVERYTHING = 1 Apache configured as follows: ./configure --prefix=/opt/wstr/apache \ --with-perl="/usr/bin/env perl" \ --activate-module=src/modules/fastcgi/libfastcgi.a \ --activate-module=src/modules/perl/libperl.a \ --activate-module=src/modules/mod_auth_ldap/mod
Testing
Hi there, I am new to this list and new to mod_perl in general, so I hope the more experienced folks will be able to help me. :) We are starting to test our perl code running under mod_perl. We did go through the porting guide and did everything that was receommended. I am interested in how people setup their Apache 1.3.x servers to run mod_perl'able code. Not, how to get mod_perl to run something, we do that with rewrite rules. I am more interested in config settings that control for performance and stability. I am also very concerned about testing. How do you test a mod_perl system to make sure there is no memory corruption from one instance of an app to another. I have thought about setting MaxServers to 1 and MaxClients to 1, to force the same compiled perl code to be reused, but I am not sure that is agood test. Is there any documentation on testing a mod_perl app? I have yet to find anything. Again, I appreciate the help and I hope to become an active member of this list. Regards...Michael --- IT Director/System Admin Globalware Solutions Redwood City, CA. - Original Message - From: "Ged Haywood" <[EMAIL PROTECTED]> To: "Jim Morrison [Mailinglists]" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, January 21, 2003 6:37 AM Subject: Re: [OT] MLDBM Size Limit?? > Hi there, > > On Tue, 21 Jan 2003, Jim Morrison [Mailinglists] wrote: > > > Sorry this is a little off topic... Is there a size limit on DBM's? (Or > > Linux files for that matter.. ) > [snip] > > Thing is I'm getting a "write error" and it seems to always happen when > > the DBM gets to 2.0Gb .. > [snip] > > Linux hope 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown > > I only have gdbm, which doesn't have at least some of the dbm restrictions, > so I don't know about dbm files. There are some cautions about dbm files > in the mod_perl Guide. > > For Linux files it depends on the filesystem you're using and how it was > initialized. For example I use ext2 (most will), and in my copy of the > documentation (it's for 2.4.19) it gives a list of file and filesystem > sizes for different block sizes. (I won't post the whole thing as it's > over 17kBytes:). > > -- > Filesystem block size: 1kB2kB4kB8kB > > File size limit: 16GB 256GB 2048GB 2048GB > Filesystem size limit: 2047GB 8192GB16384GB32768GB > > There is a 2.4 kernel limit of 2048GB for a single block device, so no > filesystem larger than that can be created at this time. There is also > an upper limit on the block size imposed by the page size of the kernel, > so 8kB blocks are only allowed on Alpha systems (and other architectures > which support larger pages). > -- > > Check out linux-2.4.7/Documentation/filesystems/ext2.txt or whatever > you have on your system. You might want to consider using gdbm, your > data could then be "as large as you want" according to the manpage... > > 73, > Ged. >
Re: PerlSections grief with VirtualHosts
I'm sorry everyone, this seems to be a case of RTFM. I refined my search criteria, and found a relevant thread on the mailing list archives that solved the problem. In particular, this message: http://www.mail-archive.com/modperl@apache.org/msg27132.html led me in the right direction. Instead of recompiling, I'm simply not use'ing XML::LibXSLT globally. I apologize for the list noise; it was late at night (or _really_ early in the morning, depending on your perspective)...yeah, that's a good excuse. :) -man Stas Bekman wrote: Michael A Nachbaur wrote: I'm pulling my hair out. I have an extremely complicated section that I'm trying to load in Apache, and I'm having one hell of a time debugging everything. To make a long story short, I'm defining multiple virtualhosts that each are configured to run AxKit. I have my Perl section defined in a separate file, and Include it into my main httpd.conf. I have some debugging code that dumps the PerlSections data to STDOUT when the server starts up. When Apache starts, it dies silently with a core dump (after outputting the Data::Dumper representation of my PerlSections). If I copy/paste the outputted Perl code and re-munge it into Apache's configuration syntax and include this file, the server starts without a problem. Therefore, I know there isn't a problem with the modules I'm loading in the virtualhosts, but I can't seem to track the problem down because I can't get any debugging information. First of all I assume that you are talking about mod_perl 1.0 here. You need to get a core file and send in the backtrace as explained here: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems If you can't get it see the tips at: http://perl.apache.org/docs/2.0/devel/debug/c.html#Getting_the_core_File_Dumped __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
PerlSections grief with VirtualHosts
I'm pulling my hair out. I have an extremely complicated section
that I'm trying to load in Apache, and I'm having one hell of a time
debugging everything.
To make a long story short, I'm defining multiple virtualhosts that each
are configured to run AxKit. I have my Perl section defined in a
separate file, and Include it into my main httpd.conf. I have some
debugging code that dumps the PerlSections data to STDOUT when the
server starts up. When Apache starts, it dies silently with a core dump
(after outputting the Data::Dumper representation of my PerlSections).
If I copy/paste the outputted Perl code and re-munge it into Apache's
configuration syntax and include this file, the server starts without a
problem. Therefore, I know there isn't a problem with the modules I'm
loading in the virtualhosts, but I can't seem to track the problem down
because I can't get any debugging information.
Here's the strace log for "httpd -X" (actually, just the last few lines,
since it's 7262 lines long). Any idea what might be wrong?
open("/etc/group", O_RDONLY)= 4
fcntl64(4, F_GETFD) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
fstat64(4, {st_mode=S_IFREG|0644, st_size=940, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x4002d000
read(4, "root:x:0:root\nbin:x:1:root,bin,d"..., 4096) = 940
close(4)= 0
munmap(0x4002d000, 4096)= 0
read(3, "s point forward you must specifi"..., 4096) = 4096
read(3, "ly text or HTML documents, \"text"..., 4096) = 4096
read(3, " .ahtml\n#\n# EBCDICConvertByType "..., 4096) = 4096
read(3, "u to place a short description a"..., 4096) = 4096
read(3, "ere. You probably want to change"..., 4096) = 4096
read(3, "/1\\.0\" force-response-1.0\n\n
getuid32() = 0
geteuid32() = 0
getgid32() = 0
getegid32() = 0
time([1042723461]) = 1042723461
rt_sigprocmask(SIG_BLOCK, NULL, [RT_0], 8) = 0
stat64("/usr/lib/perl5/site_perl/5.6.0/i386-linux",
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/usr/lib/perl5/site_perl/5.6.0", {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
open("/dev/null", O_RDONLY) = 4
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
fstat64(4, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
--
Michael A Nachbaur <[EMAIL PROTECTED]>
http://nachbaur.com/pgpkey.asc
"`That young girl is one of the least benightedly
unintelligent organic life forms it has been my profound
lack of pleasure not to be able to avoid meeting.'"
-- Marvin's first ever compliment about anybody.
The best place for mod_perl beginners to get started.
To those of you on this mailing that wonder what is the best way to get started with mod_perl should check out "Writing Apache Modules with Perl and C". This book is coauthored by Lincoln Stein (creator of CGI.pm) and Doug MacEachern (creator of mod_perl). I am only half way through the book and have increased my understanding of mod_perl 100%. And for your info, I bought the book used from Amazon.com for 5 dollars. Best book I have ever purchased by O'Reilly (next to Programming Perl) Michael Shirk Bel Air, MD http://www.shirkdog.com _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus
Re: [mp2] APR::Socket::recv set read timeout ?
> Michael wrote: > > Hi all. > > > > As suggested by Geoff and Stas, I am trying out modperl2.. Now I have > > some questions: > > > > i) with Apache::CommandServer (can be found at > > http://perl.apache.org/docs/2.0/user/overview/overview.html#toc_Protocol_Mod ules_with_mod_perl_2_0), > > I setup everything according to the guide..but > > > >> telnet localhost 8084 > >Trying 127.0.0.1... > >Connected to localhost (127.0.0.1). > >Escape character is '^]'. > > > >Login: foo > >Password: foo > >^] > > > > I must hit return once before the 'Login' prompt appears, and after a > > few tests I found that $socket->send() do not send the buffer to the > > client right away. Is this related to some configurable directives in > > httpd.conf or I did something wrong.. or just a feature? > > I'm trying to bring the overview and design notes docs up-to-date, Doug > wrote them long time ago and things have changed a bit since then. The > almost up-to-date version of the overview is here: > http://perl.apache.org/docs/2.0/user/intro/overview.html > How did you get to the old URL? Via google? I think I found that link somewhere in the user guide, but I am not sure anyway. > > ii) is there any way to perform a select(2) or like on the $socket? I > > would like to implement some sort of 'timeout' in the read loop..say, > > after 5 secs if nothing is recv'd from the client then the connection > > will be closed. I have tried alarm/die pair but it was a failure. Any idea? > > You have the APR::Socket object, so it should be possible. Though I see > that apr_poll_ API is not glued. > > !MODULE=APR::Poll > apr_poll_socket_add > apr_poll_socket_clear > apr_poll_data_get > apr_poll_revents_get > apr_poll_socket_mask > apr_poll > apr_poll_socket_remove > apr_poll_data_set > apr_poll_setup > > The ! mark in xs/maps/apr_functions.map disables the glueing of this API > subset at the build time. sorry but I would like to ask how do I glue that? I tried the util/xs_check.pl in the modperl2 src dir, and it reports.. unable to glue 27 mapped functions: ap_allow_standard_methods ap_register_input_filter ap_register_output_filter apr_brigade_printf apr_brigade_puts apr_brigade_write apr_getnameinfo apr_parse_addr_port apr_poll apr_poll_revents_get apr_poll_setup apr_poll_socket_add apr_poll_socket_clear apr_poll_socket_mask apr_poll_socket_remove apr_pool_child_cleanup_set apr_pool_cleanup_kill apr_pool_cleanup_run apr_pool_get_abort apr_pool_note_subprocess apr_pool_userdata_get apr_pool_userdata_set apr_shutdown apr_socket_addr_get apr_socket_data_get apr_socket_data_set apr_socket_from_file Finally, as I've mention before, I would like to put this non http thing together with other http things on the same port 80. Is this possible? say, when this handler sees GET|POST|HEAD it forgets the request and let the Apache HTTP module process it in the normal way?
[mp2] APR::Socket::recv set read timeout ?
Hi all. As suggested by Geoff and Stas, I am trying out modperl2.. Now I have some questions: i) with Apache::CommandServer (can be found at http://perl.apache.org/docs/2.0/user/overview/overview.html#toc_Protocol_Modules_with_mod_perl_2_0), I setup everything according to the guide..but > telnet localhost 8084 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. Login: foo Password: foo ^] I must hit return once before the 'Login' prompt appears, and after a few tests I found that $socket->send() do not send the buffer to the client right away. Is this related to some configurable directives in httpd.conf or I did something wrong.. or just a feature? ii) is there any way to perform a select(2) or like on the $socket? I would like to implement some sort of 'timeout' in the read loop..say, after 5 secs if nothing is recv'd from the client then the connection will be closed. I have tried alarm/die pair but it was a failure. Any idea? Thanks in advance. Michael
Database Pooling
Howdy. I'm very new to mod_perl, so if this question makes no sense, say so :) My understanding is that database access via mod_perl is pooled, but only per-httpd. So if I had 10 active httpds running, I would have 10x(number of connections per pool). In contrast, my Java/JSP/Servlet solution has a single pool. I'm trying to evaluate mod_perl to use instead of my current Java-based solution, but the potentially high number of database connections scares me. Do production, public mod_perl-based sites have 10s or 100s of database connections open? Any direction will be appreciated. Michael __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Shroud+ Perl obfuscator....
> And if they do have something to protect, they should put their > thinking caps on and realize that this sort of "security" is called > obfuscation for a reason: it does not accomplish anything except to > make the results hard to read. If you're giving away or selling the > perl source, obfuscating it doesn't have any significant effect. I beg to differ. Crypt::License turns the perl source into a non-text file that appears to be pure "binary" when you try to open it. There is less info readable than you would find in the average "C" object. That is what is distributed to the target machines for execution. Only the decrypt engine can decode the file in the presence of the necessary key ... and then, it goes directly into the perl intrepreter. Sure, a clever person could recover it at that point, but the point of most of these exercises is to make it not convenient or cost effective to do so. It works quiet nicely with mod_perl as well as autoloadable modules Michael
Re: How big are your httpd's?
Nate Campi wrote: On Sat, Dec 14, 2002 at 04:50:25AM +0100, Axel Andersson wrote: Hi everyone, I would like to ask you how big your mod_perl enabled (v1) httpd's grow. I'm using a homegrown publication system based on Template Toolkit that delivers about 2000 Perl pages daily. After the first page load, the daemons consume around 7 MB of RAM each, but after 24 hours they've grown to something around 12 MB, with a record-holder of 16 MB. To me this seems like quite a lot, but I would like to get some numbers from other people as to what's normal. My server gets around 2000 hits per day, and the httpd's are between 15 and 17M. To keep memory consumption to a minimum though, I follow the recommended configuration of running a reverse proxy in front of my heavy-weight mod_perl Apache. In this configuration, I have squid handle about 10 requests per single request that hits my mod_perl server, freeing up memory and CPU on both my Apache and database servers, while increasing percieved performance. AFAIK, Mandrake's stock Apache comes configured to do this quite well.
Apache perl question. May be off topic.
Sorry if this is off topic. I am attempting to take a perl script I already have written to do something before attempting to port it to modperl. I have used this method to pass request to certain files to be redirected to a perl script to produce dynamic content. However, sometimes I would just like to pass it back to apache. I know that this will be possible with modperl by returning DECLINED. AddHandler RTS-protected-htm htm Action RTS-protected-htm /cgi-bin/content_manager/handler.pl My question: Is it possible to do this with perl. I want to be able to pass some request for static documents that should end in .htm back to apache and let apache send them out throuhg the normal channels. Thanks John michael
Re: Apache::DB and perl 5.80
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday, Nov 28, 2002, at 00:25 US/Pacific, Rob Mueller wrote: I've noticed a few comments around the web of problems with 5.8.0 and Apache::DB, but no responses that anyone is looking at it or has a solution. I've had much the same problem in OS X with 5.8.0, and even asked herebut no-one seemed to know anything (or at least no-one who did noticed my email ;) ) ~www/bin/httpd -X -Dperldb [notice] Apache::DB initialized in child 2076 [Thu Nov 28 03:24:44 2002] [error] No DB::DB routine defined at /usr/local/lib/perl5/5.8.0/i686-linux/lib.pm line 10. Compilation failed in require at conf/startup.pl line 21. BEGIN failed--compilation aborted at conf/startup.pl line 21. Compilation failed in require at (eval 6) line 1. Does anyone know is anyone is looking into this or if there's a solution floating around? I'd love to be able to get it working as well Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (Darwin) iD8DBQE95d4kilk3LUlIL0MRAnFFAKDvfCe3omre/URaqGyIV173EWkvDACg01xa llFbL019nQxnSSAOOSPodM8= =arKd -END PGP SIGNATURE-
RE: Obfusacating the source
I am in the process of releasing these two modules which together provide perl source obfuscation. They are not uniquely Apache oriented though I've never used them for anything else, thus the designation in "Crypt". They have been used in production for over 2 years with little in the way of updates so they could be termed "stable". The name has been changed so that it fits into the CPAN hierarchy a little better. Crypt-CapnMidNite-1.00.tar.gz Crypt-License-2.00.tar.gz They may be found at: http://www.bizsystems.net/downloads/other README from Crypt::License Crypt::License This module set provides tools to effectively obfuscate perl source code and allow it to be decoded and executed based on host server, user, expiration date and other parameters. Further, decoding and execution can be set for a system wide key as well as a unique user key. In addition, there are a set of utilities that provide email notification of License expiration and indirect use of the encrypted modules by other standard modules that may reside on the system. i.e. sub-process calls by Apache-AuthCookie while not in user space. Tools and Makefile.PL additions are included to allow the creation of encrypted distribution "binaries" with commands make crypt make cryptdist Basic operation: Encryption uses a modified RC4 algorithim to convert the text perl file into a "binary" consisting of bits -- this is a non-text file. When perl attempts to load the module if first encounters "use Crypt::License;" at the beginning of the file which in turn decrypts the stream of "bits" and delivers it directly to the perl interpreter. Details in the POD's Michael
Re: problem with session ids
Minas wrote: Recently I installed the Apache::Session module on my server in order to give a kind of identity to my e-shop visitors, seems to work but generates different session ids when I reload the bellow test cgi. What can I do in order to have my visitor the same session id, up to close his web browser. I've run into problems recently with sessions being re-created, and discovered that the first cookie was being created in a sub-directory of my site (e.g. foo.com/a/b.xsp), but a new session was being created when other pages were loaded elsewhere in my site (e.g. foo.com/c/d.xsp). When I created the cookies, I was accepting all the defaults, so the cookie was being limited to the sub-directory of my site. My fix for this was to explicitly set the PATH variable of my cookie to be set to "/". This might be your problem. -- -man Michael A Nachbaur The best way to predict the Future is to invent it. PGP Public Key at http://www.nachbaur.com/pgpkey.asc PGP Key fingerprint = 83DC 7C3A 3084 6A21 9A3F 801E D974 AFB4 BFD7 2B6F
Re: OO handlers
Geoffrey Young wrote:
interesting. the last time I tried was with bleedperl before 5.8 was
released - I know it worked then because I was writing a patch for
mod_perl core based on it. this thread has most of the dialogue:
Hrm. Well, not sure how the :method attribute is implemented, but what
I was trying to do was create a :Profiled attribute handler. So in my
base class I had:
use Attribute::Handlers;
sub Profiled ATTR(CODE) { ... }
and in a subclass:
sub foo :Profiled {
}
but I was never able to get the Profiled handler to get called. I
looked into Attribute::Handlers and it has INIT and CHECK blocks that
set up the handlers in it, so I suspected this might be the problem.
Doug claims that CHECK blocks dont work because perl calls CHECK blocks
during perl_parse(), which only happens once at startup. So he said
that it doesnt work for the same reason that:
perl -e 'eval qq(CHECK { print "hello world" })'
doesnt work.
I tried just putting a CHECK block with a warn in my application, and it
is true that the the CHECK block never gets called. So given that it
seems impossible that the Attribute::Handlers module can work under
mod_perl.
Given that though, I dont doubt that the :method handler works for you
:). Maybe this is implemented as a special case in mod_perl??
Mike
Re: Getting the server to parse files after the handler has doneits work...
Luis Fagundes wrote: I think you can only do this in Apache 2.0. In Apache 1.3 you can chain perl modules with OutputChain, but you can't chain a perl module and another apache module. You CAN do this in 1.3 using Apache::Filter and Apache::SSI. I replied privately to Simran pointing him to these modules, but forgot to CC the list. Anyway, just wanted to clarify to the list that this is definately possible with 1.3 in case others were curious :). Regards, Mike
Re: OO handlers
Geoffrey Young wrote:
keep in mind that neither book mentions the use of subroutine
attributes, which is allowed in 1.3 but the only way in 2.0
sub handler : method {
...
}
I am 99% sure that Attribute handlers wont work in 1.3 because
Attribute::Handlers use CHECK{} blocks to set up the handlers. CHECK
blocks do not work in mod_perl under Apache 1.3 (search the list
archives for the reason). So because CHECK blocks never execute in
mod_perl under Apache 1.3 attribute handlers wont work. I tried to get
them work in under Apache 1.3 a few months ago, and gave up because of
the CHECK restrictions.
Mike
Apache::DB failing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'm trying to get Apache::DB working, but currently, I am failing. I have used it previously with perl 5.6.1, but I have upgraded to 5.8 and I can't get it to work. Other mod_perl stuff works fine (I recompiled mod_perl and apache after upgrading Perl). the error I get is, [mac47gbcri:/opt/local] mike% sudo ./sbin/httpd -X -D PERLDB [notice] Apache::DB initialized in child 29483 [Tue Nov 5 17:27:55 2002] [error] No DB::DB routine defined at /opt/local/lib/perl5/5.8.0/Exporter/Heavy.pm line 4. BEGIN failed--compilation aborted at /opt/local/lib/perl5/5.8.0/Exporter/Heavy.pm line 4. Compilation failed in require at /opt/local/lib/perl5/5.8.0/Exporter.pm line 16. BEGIN failed--compilation aborted at /opt/local/lib/perl5/site_perl/5.8.0/darwin/DBI.pm line 243. Compilation failed in require at /opt/local/lib/perl5/site_perl/5.8.0/Apache/DBI.pm line 4. BEGIN failed--compilation aborted at /opt/local/lib/perl5/site_perl/5.8.0/Apache/DBI.pm line 4. Compilation failed in require at /opt/local/etc/apache/startup.pl line 6. BEGIN failed--compilation aborted at /opt/local/etc/apache/startup.pl line 6. Compilation failed in require at (eval 6) line 1. Syntax error on line 55 of /opt/local/etc/apache/local.conf: No DB::DB routine defined at /opt/local/lib/perl5/5.8.0/Exporter/Heavy.pm line 4. BEGIN failed--compilation aborted at /opt/local/lib/perl5/5.8.0/Exporter/Heavy.pm line 4. Compilation failed in require at /opt/local/lib/perl5/5.8.0/Exporter.pm line 16. BEGIN failed--compilation aborted at /opt/local/lib/perl5/site_perl/5.8.0/darwin/DBI.pm line 243. Compilation failed in require at /opt/local/lib/perl5/site_perl/5.8.0/Apache/DBI.pm line 4. BEGIN failed--compilation aborted at /opt/local/lib/perl5/site_perl/5.8.0/Apache/DBI.pm line 4. Compilation failed in require at /opt/local/etc/apache/startup.pl line 6. BEGIN failed--compilation aborted at /opt/local/etc/apache/startup.pl line 6. Compilation failed in require at (eval 6) line 1. A similar error is produced no matter what module I try and use when in my startup.pl, or if I don't use that, when the first script is compiled. Perhaps Exporter wasn't built properly (and thus presumably, the rest of perl), or Perl 5.8.0 doesn't get on with Apache::DB, or? thanks in advance Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (Darwin) iD8DBQE9yHDfilk3LUlIL0MRAg9jAKDEXui79Kk/T6ytvu0mHq2pi29K3ACg2rYD HieYfzJnos0r+iBnblR5Qbc= =zW0O -END PGP SIGNATURE-
Re: [OTish] Version Control?
"perl Makefile.PL < /dev/null" works for us. We encapsulate it in a macro (see below). Now why didn't I think of that? :). This works nicely. We still ahve to patch some of the individual Makefile.PL's, but that is acceptable (some of them have "exit;" at the end of them for example which causes the Makefile generation to stop :)). We use a vendor branch to import the new versions of modules as we update, and CVS handles this fairly well. Mike
Re: [OTish] Version Control?
Okay, I'll chime in on this one. I work on a medium sized mod_perl project (approximately 50,000 lines of perl code). This project is managed similarly to to the setups that have been described so far. We store all of our CPAN module sources in CVS, and currently we distribute the modules to the servers via RPM. Its critical that we maintian sources to the CPAN modules in CVS because some modules have to be patched to make the modules work for this particular project (and some modules just plain have bugs :)). The modules get installed in the main perl directory (e.g.: /usr/lib/perl5). We use cvs branches to manage releases and development versions of the web site and perl code. When we get to a realease point we make a branch (e.g.: RELEASE-1_0), and html developers continue working on that branch for changes to the currently released site. The web servers can be updated with simply "cvs update" this way. On the main trunk perl/web development continues until the next release happens. However, due to the fact that the CPAN modules are distributed via RPM, there are various incompatibility problems that come up. For example, one time we upgraded Apache::Filter between releases. Unfortunately, the old version was not compatible with the new version, so a single machine could run either the current release branch, or the development branch, but not both simultaneously (because Apache::Filter was incomptaible and was installed under /usr/lib/perl5). So currently we are looking into also installing CPAN modules under the project directory and managing the binary CPAN modules CVS, which would solve this problem. Developers could check out a sandbox of the release branch and they would get the modules that belong to that release (binary compatibility is okay because our development machines match the production machines). The management nightmare to all of this is that automating the build process for lots of CPAN modules (rougly 110 of them) is painful. Our CPAN source tree looks something like this: project-support/ src/ Makefile Apache-Filter/ CGI/ Digest-MD5/ ... First we tried making a Makefile.PL in "src" that used the DIR attribute of WriteMakefile to specify the subdirs to build all of the modules. THis didnt work so well. The problems with this are: 1) some Makefile.PL's refuse to generate a Makefile if PREREQ_PM's are not satisfied (if we haven't built them yet) 2) some Makefile.PL's are INTERACTIVE, and you cant turn it off (e.g.: Apache::Filter requires you to hit a number of times at a MINIMUM. So we resorted to a set of overly-complicated GNUmakefiles that would generate Makefile's from Makefile.PL's, and these would set PERL5LIB to find the dependencies (e.g.: DBD-Pg would put ../DBI/blib into PERL5LIB). I'm not convinced this is the best way to go about it, but it "sort of" works. How does everyone else cope with this (managing trees of CPAN modules / CPAN module tree build environments)? Maybe we are sort of unique in that we use so many 3rd part CPAN modules, but because we use so many of them its pretty critical that we manage them in CVS. Mike
interesting hang...
My apologies if this is a FAQ, I haven't been able to figure it out &
can't find the answer online anywhere.
I have a fairly extensive script I've written to display tables of
information about equipment for an online game. For some reason the
script is hanging at at least two points:
At one point in the code I have it print a link to another page, but
passing the same $ENV{'QUERY_STRING'} that was passed in to begin with.
I don't know why, but it hangs. There are no unusual characters in the
string, I've checked that; I even went so far as to escape the quotes
defining the URL in the link, but still no luck. Here's the relevant
lines as they are presently written:
$pass = "/cgi-bin/plaintextresult.cgi?$ENV{'QUERY_STRING'}";
#print "$pass\n";
print "\n";
print "Submit unlisted equipment\n";
print "Plain text version\n";
It's the last line there that hangs. Note that if I uncomment the line
that just prints the query string on its own, it doesn't hang.
I also have other strange hangs in here, but I haven't yet been able to
figure out which exact lines are causing the problem.
For the ppl who can figure this stuff out just by install data:
I'm running Redhat 8.0, Apache 2.0, on a p3-450. This entire
application did work correctly under Redhat 7.3 (Skipjack), Apache 1.3.
Unfortunately I upgraded...
Thanks,
Michael L. Forbes
[EMAIL PROTECTED]
For those who'd like to see the page in operation, it's at
parailtrail.dyndns.biz/cgi-bin/index.cgi
Re: hangs on $ENV{'QUERY_STRING'}
Well, I've managed to make some significant progress: I got past that
hang (apparently modperl was having problems with the URL b/c some of
the values were being passed empty... i.e.,
"stage=4&eqtype=All&cont=&restrictflags=12"... notice that cont has no
value.
At any rate, I solved that problem by forcing the form that passes the
information in to always have at least a bare minimum of data in each
field... and it seems to be working.
My next problem, which took four hours to track down, is that it turns
out that mod_perl is choking on null values being retrieved from MySQL.
I'm using DBI for the interface, and the actual fetch_row is performing
exactly the way it should... but when it tries to do anything with my
scalar once it has a null in it, it just chokes & sits there until it
times out. Is this a known bug? Is there a known fix for it, other
than ensuring I never have null values in my database?
Thanks,
Mike Forbes
[EMAIL PROTECTED]
On Wed, 2002-10-30 at 17:53, Michael Forbes wrote:
> My apologies in advance if this is something that's been described &
> solved before... I can't seem to find the answer in archival searches
> (maybe I'm just using the wrong terms).
>
> At any rate, I have a fairly large script that I wrote when operating
> under Apache 1.3, perl 5.8.0, Redhat 7.3. I'm now running Apache 2.0,
> perl 5.8.0, and Redhat 8.0... and it stopped working when I performed
> the upgrade.
>
>
> Anywhere, what's happening is that the code below this paragraph is just
> hanging...(on the second line, I've inserted a few "print
> 'debug\n';" lines in the real thing to make sure.) it does finally
> time out, without producing any output.
>
> here's the relevant code:
>
> $pass = "/cgi-bin/plaintextresult.cgi?$ENV{'QUERY_STRING'}";
>
> print " HREF=\"$pass\" target='printerfriendly'>Plain text version\n";
>
>
>
> Thanks in advance, and again, sorry if this is a FAQ, I just couldn't
> find the answer anywhere.
>
> -Mike Forbes
> [EMAIL PROTECTED]
>
>
Re: [OT] Re: Yahoo is moving to PHP ??
On Wed, 30 Oct 2002, Richard Clarke wrote: > List, > You are probably not the best people to ask for an answer which > might advocate PHP, > but. > Can someone who is more proficient in PHP than I (I have used it > for 5 minutes) explain to me why it is quicker to prototype things in PHP? ---> it isn't. PHP blows.
Re: Yahoo is moving to PHP ??
On Thu, 31 Oct 2002, Gunther Birznieks wrote: > You would think if they want an anal scripting language they would move > to python not PHP. :) Python isn't anal--it's a very clean, interesting, flexible language on par with perl--perhaps superior in some ways and not as good in others but, overall, on a similar scale. In respect to the article, to me, anyway, most of the arguments weren't particularly compelling from my outside viewpoint. The one point they made was true--PHP was developed specifically for the web and doesn't have the wide variability of perl (they seem to equate extensive flexibility, as a trouble point leading to great variance in the code -- stylistically and logically). I don't think this problem is neccessarily eliminated comprehensively by switching to a crappy language like PHP. Some standardization could be achieved via coding guidelines, approved practices, code reviews etc. while still retaining the power and flexibility of a perl. Many of the problems they associated with perl aren't neccessarily eliminated by using PHP, including the issues with code variance. They still stated that perl would fuel many things on the backend, though, so they haven't gone completely mad. -mj > John Saylor wrote: > > >Hi > > > >( 02.10.30 03:22 -0500 ) Perrin Harkins: > > > > > >>They didn't make their decision on performance though. They seem to > >>have been most influenced by the idea that perl allows too much > >>flexibility in coding style, although I can't see how PHP is going to > >>help with that. > >> > >> > > > >Wow, I'd like what *they* had for lunch! > > > >Quasi-seriously, as someone who has had to maintain mountains of bad > >perl code, I know TMTOWTDI can have a downside; but the openness of the > >language is what has lead to its greatness ... > > > > > > >
hangs on $ENV{'QUERY_STRING'}
My apologies in advance if this is something that's been described &
solved before... I can't seem to find the answer in archival searches
(maybe I'm just using the wrong terms).
At any rate, I have a fairly large script that I wrote when operating
under Apache 1.3, perl 5.8.0, Redhat 7.3. I'm now running Apache 2.0,
perl 5.8.0, and Redhat 8.0... and it stopped working when I performed
the upgrade.
Anywhere, what's happening is that the code below this paragraph is just
hanging...(on the second line, I've inserted a few "print
'debug\n';" lines in the real thing to make sure.) it does finally
time out, without producing any output.
here's the relevant code:
$pass = "/cgi-bin/plaintextresult.cgi?$ENV{'QUERY_STRING'}";
print "Plain text version\n";
Thanks in advance, and again, sorry if this is a FAQ, I just couldn't
find the answer anywhere.
-Mike Forbes
[EMAIL PROTECTED]
Re: [RFC] Apache-GeoIP module
darren chamberlain wrote: One thing I'd add if you do decide to use the Geo::IP module, it does not behave as documented if it does not find a match. The docs say it returns "undef", but in fact it returns the string "--". The attached patch fixes that problem. I've sent the patch to the GeoIP folks, and got no reply. I'll try sending it to [EMAIL PROTECTED] and see if someone gets it that way :). Mike Index: IP.xs === RCS file: /usr/local/cvsroot/gkgnsi-support/src/Geo-IP/IP.xs,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- IP.xs 22 Aug 2002 20:30:43 - 1.1 +++ IP.xs 22 Aug 2002 20:32:55 - 1.2 @@ -39,8 +39,14 @@ country_code_by_addr(gi, addr) GeoIP *gi char * addr +PREINIT: +char * code; CODE: - RETVAL = (char *)GeoIP_country_code_by_addr(gi,addr); + code = (char *)GeoIP_country_code_by_addr(gi,addr); +if (*code == '-') +RETVAL = NULL; +else +RETVAL = code; OUTPUT: RETVAL
Re: [RFC] Apache-GeoIP module
darren chamberlain wrote: attached to Apache. I'd like to see, in addition to the Apache stuff, a generic GeoIP library that can be used from outside Apache, like in log-eating scripts. You mean like this? http://search.cpan.org/author/TJMATHER/Geo-IP-0.26/lib/Geo/IP.pm :) Mike
Re: AuthCookie questions
Christian Gilmore wrote: 1. Read data from existing cookie. 1a. Redirect if cookie is non-existent. 2. Accept or reject cookie. 2a. If rejected, redirect. 2b. If accepted, populate environment and return. Sounds to me like you really dont need AuthCookie at all. You could just as easily do all of this by writing a PerlAccessHandler that does the above things. I'll second Perrin's comments. You definately have security problems with this. The only way to do this securely is to cryptograpically sign the cookie and to encrypt the data on the wire using SSL. Mike
Re: protecting and entire site with AuthCookie and its derivatives?
George Valpak wrote: Is it possible to protect an entire site, from DocumentRoot, using AuthCookie? Yes. I've never done this myself personally, but people have reported success doing this. The trick is to configure apache so that your LOGIN handler is not inside the authentication realm. Since your wanting to protect the whole server, the trick is to use LocationMatch directives to specify that everything EXCEPT /LOGIN (or whatever your login handler is) gets protected. I dont have a configuration to post to you that will work because I've never done it, but its definitely possible becuase others have had success with it. Mike
Re: AuthCookie questions
Christian Gilmore wrote: 4. I cannot modify the cookie and should not send additional cookies. [snip] about 4. Can I use an unmodified AuthCookie to ensure that whatever format the inbound cookie is in is sufficient and will not need to be modified or supplemented? I believe the answer is no, and, if it is, should this be What exactly do you mean by this? What are you trying to accomplish? Do you mean "The user cannot modify the cookie?" If thats what you mean, then yes, there are ways to do that. Basically you have to cryptographically sign the cookie using a secret that is unknown to the end user. There is an example of this in the Eagle book, and Apache::AuthTicket uses a scheme similar to this. Because you cant control what the cookie server sends, you'd probably have to do some sort of double redirect For example: o user is redirected to auth server o auth server returns cookie and redirects to /SIGNHANDLER o signhandler gets the cookie, cryptographically signs it, and returns the cookie to the client and redirects to real location o user is redirected to real location. If thats not what you mean, please elaborate. Regards, Mike
Re: Apache::AuthCookie in mod_perl 1.99_5
Any comments? AuthCookie has not yet been ported to mod_perl 2.0. Mike
Re: perl script not reloading
I did this and it still doesn't reload the script. I added it just after the LoadModule: LoadModule perl_modulelibexec/apache/libperl.so PerlInitHandler Apache::StatINC It's a single main script, not a module. It uses CGI. This is the first time I've ever written a perl script that runs inside apache (but I've been programming perl for several years). It used to reload the script automatically, but for some reason, as I added more and more stuff to my script, it doesn't anymore. It seems like something I did but I can't figure out what. I don't really want to post the entire script to the list, if anyone wants to volonteer to have a look, let me know and I'll send it to you. It's a fairly simple sort of script to read in stuff from a form and stick it in a database, and return a table showing what's in the database. > Add the following to httpd.conf: > > # Stat the modules so changes don't require the server > # to be restarted > PerlInitHandler Apache::StatINC > > This module does a file stat on your scripts and reloads if there > has been a change. > > It seems that as I work on my script, Apache doesn't reload it when > > the script changes on disk. > > > > It seems like it's something that I did because it used to. Is there > > some common well known thing or set of things one can screw up to make > > this happen? > > > (if so, it should be documented in the mod_perl_traps man page). > > > > Michael Grant > >
perl script not reloading
It seems that as I work on my script, Apache doesn't reload it when the script changes on disk. It seems like it's something that I did because it used to. Is there some common well known thing or set of things one can screw up to make this happen? (if so, it should be documented in the mod_perl_traps man page). Michael Grant
Re: BUG:Apache::Cookie v1.0
>> * Michael McLagan <[EMAIL PROTECTED]> [2002-09-21 11:45]:
>> > There is a bug in Apache::Cookie. It doesn't handle a cookie with
>> > zero bytes in it!
>
>> This is because Apache::Cookie is implemented in C, and C uses NULL as
>> the end of string terminator.
>
>No quite accurate. C has no concept of a string. There are a number of
>library functions for string handling that use '\0' as the string
>terminator.
>
>If somebody rewrites Apache::Cookie to replace those functions, it will
>be able to handle such cookies.
>
>> This is probably something that needs to be done in Perl, since I doubt
>> there's a way to check for "embedded" NULLs in a string in C...
>
>/* We assume there will always a '\0' to be found. */
>char *
>find_nul(char *str)
>{
> while (*str) {
>str++;
> }
>
> return str;
>}
>
>What interests me much more is *why* a cookie should be able to contain
>*any* control character. If you want binary data in a cookie, you should
>encode it somehow.
>
>If the '\0' was a '\n', things would be much more interesting ...
>
>Lupe Christoph
hmmm... that's not really to point. Apache::Cookie is supposed to be
modeled on and replace CGI::Cookie. If you examine the code in CGI::Cookie
you see that when the "values" are extracted from the input hash, they are
escaped and then placed into the string format used for a cookie. There is
no limitation at all on what characters may be place in the "values" that
are submitted for XXX::Cookie->new($r,%hash). The present situation really
is a bug in implementation due to the nature of the C lib used to process
the "value" portion of the cookie string. I suspect the same is true about
the cookie "name" since it is processed in a similar way in CGI::Cookie.
We're not discussing what is allowable in the cookie itself, only the
compatibility of the Apache::Cookie vs CGI::Cookie implementation on which
it is patterned.
Michael
Re: mod perl and apache with ssl and openssl
On Tue, 24 Sep 2002, Allan P. Magmanlac wrote:
> Hello,
>
>Can anyone advise me on how to build
> apache server with ssl and openssl and
> using mod perl.
>
> this is how I do it WITHOUT mod perl support
> cd to modssl soure directory and then run the following command
> ./configure \
> --with-apache=../apache_1.3.26 \
> --with-ssl=../openssl-0.9.6g \
> --prefix=/usr/local/root/httpd_1.3.26 \
> --with-crt=/usr/local/root/httpd/usr/local/www/conf/ssl.crt/server.crt \
> --with-key=/usr/local/root/httpd/usr/local/www/conf/ssl.key/server.key \
> --enable-module=proxy
>
> So how would I do it WITH mod perl support. (exact commands would
> be appreciated)
>
> Thanks
>
Sure, here's my receipe. Works every time
make sure open-ssl is built and installed
then
in apache-xxx/
untar and run the Fixpatch script for the appropriate version of
appache-ssl
rm apache/src/Configuration
rm /usr/src/apache/src/Configuration.apaci
edit /usr/src/apache/src/Configuration.tmpl and
modules, i.e.
activate mod_info.o, mod_rewrite.o, mod_so.o libproxy.a
or whatever you plan to use
then
in mod perl source directory
Run:
perl Makefile.PL \
APACHE_SRC=/usr/src/apache/src \
DO_HTTPD=1 \
USE_APACI=1 \
PREP_HTTPD=1 \
EVERYTHING=1 \
in apache directory
./configure --with-layout=Apache \
--activate-module=src/modules/perl/libperl.a
make
make install
Michael
Re: Prototypes and $r
What does MasonHandler actually look like?
-mj
On Tue, 24 Sep 2002, Ken Miller wrote:
> Got a phone call yesterday from a user who was complaining that every few
> times a link was clicked on they were getting an "Internal Server Error".
> They could click back, try again, and be successful. Further investigation
> led me to find that one of the instances of my back end server was always
> generating an error.
>
> Restarts would not fix the problem - one or two of the app servers would
> always throw errors
>
> The error was this:
>
> [Mon Sep 23 19:12:21 2002] [error] Can't call method "dir_config" on an
> undefined value at /webroot/lib/Husky/Web/Apache
> /MasonHandler.pm line 68.
>
> The line in question is this:
>
> my $appl_id = $r->dir_config( 'ApplID' );
>
> So, you can see that '$r' was undefined.
>
> The interesting thing is that the handler that's invoked for this request
> has a prototype:
>
> sub handler( $$ ) { my $class = shift; my $r = shift; ... }
>
> and the handler is either invoked by Apache directly, or from internal logic
> when a request is passed off. The handler is invoked in one of two ways:
>
> __PACKAGE__->a_method_name( $r );
>
> or
>
> Foo::Bar::Bah->a_method_name( $r );
>
> Now, it appears that every now and then the class reference is NOT being
> sent; hence, $class actually contains $r, and $r is undefined. This is
> obviously bad, since $r->dir_config dies a horrible death.
>
> Has anyone had a problem with this? Is there something that might give me a
> clue as to why this is failing? In the meantime, I've when back to
> referencing the sub directly, as opposed to going through the class. It
> works, but it's not as nice as a class method...
>
> Cheers!
>
> -klm.
>
> +-+-+
> | Kenneth (Ken) L. Miller | There are 10 kinds of people in the |
> | Shetland Software Services Inc. | world: Those who understand binary, |
> | [EMAIL PROTECTED]| and those who don't. (unknown) |
> +-+-+
>
Re: BUG: Apache::Cookie v1.0
Once upon a time, I wrote: > There is a bug in Apache::Cookie. It doesn't handle a cookie > with zero bytes in it! A clarification, it's not a zero length cookie that is mishandled, it's a cookie with an embedded NUL (zero) character. Michael
BUG: Apache::Cookie v1.0
Hello,
There is a bug in Apache::Cookie. It doesn't handle a cookie with zero
bytes in it!
$value = "ABCD" . chr(0) . "EFGH";
$cookie = Apache::Cookie->new($request, -name=> 'oatmeal', -value=> $value,
-domain=>$ENV{'SERVER_NAME'}, -path=>"/");
print $cookie->as_string;
The output looks like:
oatmeal=ABCD; domain=my.web.server.com; path=/; expires=0
Where did the rest of my cookie go?!
Should I not have gotten:
oatmeal=ABCD%00EFGH; domain=my.web.server.com; path=/; expires=0
Michael
[ANNOUNCE] Apache::Test::CookieEmulator 0.04
Test::Apache::CookieEmulator - test tool for Cookies without httpd SYNOPSIS use Test::Apache::CookieEmulator; loads into Apache::Cookie namespace DESCRIPTION This module assists authors of Apache::* modules write test suites that would use Apache::Cookie without actually having to run and query a server to test the cookie methods. Loaded in the test script after the author's target module is loaded, Test::Apache::CookieEmulator Usage is the same as Apache::Cookie [EMAIL PROTECTED]
Re: problems installing libapreq-1.0
never mind. It appears that the order in which things are done is important. I finally got it to work by reinstalling mod-perl for the umpteenth time and then again trying libapreq. Strange, the old version that was installed would no re-install until I did this. > I have two identical hosts with the following > > mod_perl-1.26 > apache apache_1.3.26 > ben apachessl_1.48 > openssll-0.9.6b > > on one, libapreq-1.0 installs just fine, on the other I get this > error: > > In file included from > /usr/lib/perl5/site_perl/i386-linux/auto/Apache/include/include/http > d.h:79, > from apache_request.h:5, > from apache_request.c:59: > /usr/lib/perl5/site_perl/i386-linux/auto/Apache/include/include/buff > .h:75: openssl/ssl.h: No such file or directory > /usr/lib/perl5/site_perl/i386-linux/auto/Apache/include/include/buff > .h:78: > #error "Don't use OpenSSL/SSLeay versions less than 0.9.2b, they have a > serious security problem!" > make[1]: *** [apache_request.o] Error 1 > > I can't figure out what the problem is. all the include files appear > to be in the same places on both machines. I've rebuilt everything > from scratch on the machine that fails :-( > > Any ideas?? >
problems installing libapreq-1.0
I have two identical hosts with the following mod_perl-1.26 apache apache_1.3.26 ben apachessl_1.48 openssll-0.9.6b on one, libapreq-1.0 installs just fine, on the other I get this error: In file included from /usr/lib/perl5/site_perl/i386-linux/auto/Apache/include/include/httpd.h:79, from apache_request.h:5, from apache_request.c:59: /usr/lib/perl5/site_perl/i386-linux/auto/Apache/include/include/buff.h:75: openssl/ssl.h: No such file or directory /usr/lib/perl5/site_perl/i386-linux/auto/Apache/include/include/buff.h:78: #error "Don't use OpenSSL/SSLeay versions less than 0.9.2b, they have a serious security problem!" make[1]: *** [apache_request.o] Error 1 I can't figure out what the problem is. all the include files appear to be in the same places on both machines. I've rebuilt everything from scratch on the machine that fails :-( Any ideas?? Michael
Re: odd authetication situation
Peter wrote:
> Maybe you can try to add specifically:
> $r->connection->user('who_the_user_is') before the cookie access control
> returns OK in the module. Note that some of the cookie authentication
> modules are based on "access-only" control so $r->connection->user() can
> return a value in late phases only if one assigns it at the first place.
Point of clarification...
The authentication I'm writing about is BASIC AUTHENTICATION. apache takes
care of all of that. It appears as though the client is not sending it,
but I don't know why ... and if not, how it manages to pass the
authentication portion of the apache request loop.
the example I'm using does the following:
.htaccess
AuthType Basic
AuthName MagicName
AuthUserFile
/home/web/public_html/cgi/private/user.access
require valid-user
scriptA.plx ->redirect to scriptB.plx
scriptB.plx ->redirect to scriptA.plx CONDITIONALLY
if the CONDITION is met, the redirect is not done
i.e. cookie present + "user" present
what happens.. scriptA always has ENV{REMOTE_USER} and
$r->connection->user valid
scriptB rarely has them both valid
either script can set the same cookie if it is not present.
The cookie is always present for scriptA and usually but not always
present for scriptB
WHY???
Michael
Re: odd authetication situation
> Maybe you can try to add specifically:
> $r->connection->user('who_the_user_is') before the cookie access
> control returns OK in the module. Note that some of the cookie
> authentication modules are based on "access-only" control so
> $r->connection->user() can return a value in late phases only if one
> assigns it at the first place.
>
>
> Peter Bi
>
hmm... let me see if I understand what you are saying
It is necessary to specify $r->connection->user('current-known-user');
before I send OK so that on the next contact by the browser to the web
server $r->connection->user will have the correct value???
Is this because of keep-alives and using the same child process??
I would think that the client would send the token for each connection.
then what about the Cookie?? It appears that gets lost sometimes,
but not as often as the authentication token. This "fuzzy" behavior makes
redirects where cookies and tokens are expected very dicey...
Michael
> - Original Message -
> From: "Michael Robinton" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, August 28, 2002 1:05 PM
> Subject: odd authetication situation
>
>
> >
> > I have a modperl handler that sets a cookie and does a redirect if the
> > cookie was not present. The redirected page eventually loads the same
page
> > again. In addition, this page is called from a protected portion of
the
> > site that requires Basic Auth.
> >
> > When the redirect calls the mod_perl routine the second or "some"
> > subsequent times, $r->connection->user and $ENV{REMOTE_USER} are both
> > empty or non-existent yet the page does not appear to fail the
> > authentication request and executes and returns html.
> >
> > The failure is repeatable though not consistently so, maybe 70% or
more.
> >
> > I'm scratching my head on this one. Any ideas??
> >
> > Michael
odd authetication situation
I have a modperl handler that sets a cookie and does a redirect if the
cookie was not present. The redirected page eventually loads the same page
again. In addition, this page is called from a protected portion of the
site that requires Basic Auth.
When the redirect calls the mod_perl routine the second or "some"
subsequent times, $r->connection->user and $ENV{REMOTE_USER} are both
empty or non-existent yet the page does not appear to fail the
authentication request and executes and returns html.
The failure is repeatable though not consistently so, maybe 70% or more.
I'm scratching my head on this one. Any ideas??
Michael
Re: naming convention
Stas wrote:
> Michael Robinton wrote:
> > I have a proposed perl / modperl module that will go to CPAN
> >
> > Graphics::ColorPicker : A perl module for WYSIWYG web
> > applications that allow selection of HEX color numbers
> >
> > I think this is an appropriate name, but have not submitted in
> > this category before. Please advise.
>
> I guess that this module is not extending mod_perl functionality,
> but simply optionally uses it and therefore you better off
> discussing this at [EMAIL PROTECTED], [EMAIL PROTECTED] without
> even mentioning mod_perl so not to confuse people. If my guess is
> wrong (you provided too little info) and it *requires* mod_perl it
> should probably be named something like Apache::ColorPicker, but
> again, you've provided too little info to tell.
Sorry bout that. It does optionally use mod_perl -- it tests
eval{require Apache} and proceeds, otherwise uses print statements to STDOUT
>
> > See: http://www.bizsystems.net/downloads/graphics/demo.html
>
> FWIW, it doesn't seem to do anything on mozilla-1.0/linux.
hmm works fine on my mozilla-1.0/linux build #2001061002
tested on above + windoze MSIE5.5, Netscape 4.7, Mozilla 1.0
If you can tell me more that would be nice.
Michael
naming convention
I have a proposed perl / modperl module that will go to CPAN Graphics::ColorPicker : A perl module for WYSIWYG web applications that allow selection of HEX color numbers I think this is an appropriate name, but have not submitted in this category before. Please advise. See: http://www.bizsystems.net/downloads/graphics/demo.html Thanks, Michael
Re: variables not changing with modperl??
Sorry, There is a my in front of the ($cookie,$user)
code. I am confused about your second statement about
parsing the input. What should I be doing? Do you
mean I should use $r->read($content,
$r->header_in('Content-length'))? to read in the
variables?
I use the AuthCookie modules to set the cookies and to
authenicate.
Mike
--- Perrin Harkins <[EMAIL PROTECTED]> wrote:
> darren chamberlain wrote:
> > Make those global symbols ($cookie, $user, and
> $hash) lexical (declare
> > with my) and the code will both compile and do
> what you expect (i.e.,
> > not maintain values from call to call).
>
> That's what I was thinking too. Also, it's really
> not a good idea to do
> your own parsing of the input and cookies. You
> should use one of the
> CGI modules or Apache::Request and Apache::Cookie
> for this. Writing
> your own routine for this is just asking for
> security problems and bugs.
>
> - Perrin
>
>
__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
Re: variables not changing with modperl??
Thanks for the link. I actually don't use functions.
Everything is mostly in MAIN. Here is a snip of code:
#!/usr/bin/perl -wT
use strict;
print "";
my $r = Apache->request;
$r->content_type("text/html");
$r->status(200);
my $auth_type = $r->auth_type;
$cookie=$auth_type->key;
($user,$hash)=split(/:/,$cookie);
read(STDIN, my $buffer, $ENV{'CONTENT_LENGTH'});
my @pairs = split(/&/, $buffer);
foreach my $pair (@pairs) {
}
What I am doing wrong? Everytime the script runs the
values of the variables coming in change. Should I
use the delete function and delete all of the
variables at the end of the script? @pairs is what
should change, but sometimes does not. I have tried
to add a undef @pairs before the split, but no luck.
Mike
--- Perrin Harkins <[EMAIL PROTECTED]> wrote:
> Michael Drons wrote:
> > I am using Apache::Registry (Apache 1.3.26) I am
> see
> > weird things happen with my scripts. I have have
> "use
> > strict" in all of the scripts and I use my() for
> all
> > of my variables. But I still have variables that
> > contain data from previous loads.
>
> Sounds like the closure problem with subroutines in
> Apache::Registry.
> Does you code have subroutines that refer to
> variables declared outside
> of them?
>
> > Everything I can find in docs says read the FAQ at
>
> > http://perl.apache.org/faq/, which does not
> exists.
>
> Read this:
>
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#my___Scoped_Variable_in_Nested_Subroutines
>
> - Perrin
>
__
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
variables not changing with modperl??
I am using Apache::Registry (Apache 1.3.26) I am see weird things happen with my scripts. I have have "use strict" in all of the scripts and I use my() for all of my variables. But I still have variables that contain data from previous loads. I see it in hashes and arrays. Especially, if I have an array that contains 6 strings in load 1 and only 2 strings in load 2. In the second load of the script the array will contain the 2 new strings and the 4 old strings. Everything I can find in docs says read the FAQ at http://perl.apache.org/faq/, which does not exists. This link comes from the subscribe message. I have thought about using PerlRun, but a module I use (AuthCookie) requies mod_perl. How do I undefine or reinit the variable? I am currently using undef, but it does not work. Mike Drons __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: Modperl! Your private *UNDERAGE* lolitas and boys!
Oden Eriksson <[EMAIL PROTECTED]> writes: > On Thursdayen den 1 January 1970 00.59, [EMAIL PROTECTED] wrote: > > > P.S. This is not spam! > > He he..., yeah right... > > How do one keep this kind of shit out of here? I'd like to know, too. I'm a resident of Virginia, USA, and the state anti-spam laws make the original mail punishable by fines (since it used falsified headers, specifically the spoofed From:). Unfortunately, apache.org's mailer wiped the Received: trail, so it's impossible to track upstream. Checking Received: headers is also my normal way of filtering out spam sent to mailing lists, so it is doubly frustrating. -- Michael Poole
Subject: Re: hiding perl code
>> BZS::License performs a similar load operation to BZS::Loader. First, >> however it looks for a hash pointer in the caller program called >> $ptr2_License. >> The hash contains the path to the License file and an optional >>'private' key >> list of modules which will decrypt only with the 'private' key. B, > I thought that somebody has already said here that you cannot hide your > perl code. if you have an access to the perl interpreter you can dump > the source code after it was decrypted. > > wouldn't it be a good idea to add the truth to the POD so not to mislead > the crowd? I've read through the doc but didn't see a word mentioning > this "little" caveat. > > Shouldn't the module be renamed to BZS::Obscure::...? ;) You are correct. If you... use Hidden::Module then use Data::Dumper to reconstruct most of the raw code. This would be about as useful as decompiling 'B' code. If you had access to the intrepreter directly, you could probably even capture the decrypt stream before perl compiles it, but all of that would take a degree of sophistication that is better used to make real money instead of hacking stuff apart. How about BZS::VeryObscure :-) Michael
hiding perl code
ules by virtue of the PerlRequire or PerlModule directives in the users
config file. B, the AuthCookie module B have a
B $ptr2_License inserted in the beginning statements.
=item 5
With all this accomplished, all modules should load and de-crypt without
problem.
=back
=head1 EXPORT
None by default.
=head1 TOOLS
makeCert.pl makes a License document
makeLicenseMod.pl makes only unsplit Licensed modules
makeCrypt.plmakes a split Licensed module
makePOD.pl separates POD from mixed module
mod_parser.pl used by makeCrypt, makePOD, makeLicenseMod
=head1 AUTHOR
Michael Robinton, [EMAIL PROTECTED]
=head1 COPYRIGHT
Copyright 2000 Michael Robinton, BizSystems.
All rights reserved.
=head1 SEE ALSO
L, L
=cut
=head1 NAME
BZS::License::Notice -- perl extension for License
=head1 SYNOPSIS
require BZS::License::Notice;
BZS::License::Notice->check($input_hash)
=head1 DESCRIPTION
=over 4
=item BZS::License::Notice->check($input_data_ptr)
$input_hash_ptr = { # optional parameters
'ACTION'=> 'default /usr/lib/sendmail -t -oi',
'TMPDIR'=> 'default /tmp',
'INTERVALS' => 'default 5d,30d,60d',
'TO'=> 'default [EMAIL PROTECTED]',
# mandatory parameters
'path' => 'path to LICENSE',
'expires' => 'seconds until expiration',
};
The B routine will send a notice message at the requested or default
intervals IF the temporary directory exists and is writeable AND if the
B parameter exists and is positive AND the LICENSE file exists and is
readable. Substitutes can be made for the default values for ACTION, TMPDIR,
TO, and INTERVALS. Valid suffixes for INTERVALS are w=weeks,
d=days, h=hours, m=minutes, s=seconds (default if no suffix).
B returns an empty array on any error or if B does not exist. It
returns an
array of the INTERVALS values in in seconds, highest to lowest, if a check
is performed.
Note that the b hash can be combined with the hash used for the
B module and that they share common variables B and
B. All other B hash keys are lower while B
hash keys are upper case.
=back
=head1 COPYRIGHT
This Library is proprietary software and may be used only with the
permission of the author.
Copyright 2001 Michael Robinton, BizSystems
=head1 AUTHOR
Michael Robinton, BizSystems <[EMAIL PROTECTED]>
Attribute Handlers under mod_perl again
Hi everyone. I've revisited using Attribute::Handlers work under mod perl again, and I am still unsuccesful. Looking at Attribute::Handlers, it appears that Attribute::Handlers relies on CHECK blocks to do its work. I verified this by uncommenting one of the debugging warnings in Handlers.pm and compiling a module that uses Attribute::Profiled on the command line. When I do this I see: Handling Profiled on CODE(0x8a6cda0) in CHECK with [] But when running the module under mod_perl, the above warning never appears int he error log. accroding to this message: http://marc.theaimsgroup.com/?l=apache-modperl&m=96639978528467&w=2 mod_perl does not, and can not, support CHECK blocks at all, so this is sort of what I would expect. Given that, I'm curious how anyone has gotten Attribute::Handlers to work under mod_perl. Does anyone have any ideas? I'm running perl 5.6.1, mod_perl 1.27, apache 1.3.27, Attribute::Handlers 0.77. Mike
Re: Mount something with my perl script
Hi, ouch, bad idea, wrong list, but: 4 solutions: 1.) let your webserver run as root (NEVER, NEVER do this!!) 2.) write a daemon that runs as root and does such things for your normal programs. (Overkill in this case) 3.) use sudo to allow the webserver's user to run exactly that command (with exactly that parameters) 4.) put that mount into your /etc/fstab with parameters "noauto, user" (noauto = don't mount at system boot time, user = allow any user to mount) cu Michael 24.07.2002 13:55:13, "Heiss, Christian" <[EMAIL PROTECTED]> wrote: > > > From: "Heiss, Christian" <[EMAIL PROTECTED]> > > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Subject:Mount something with my perl script > Date: Wed, 24 Jul 2002 13:55:13 +0200 > > > > > Hello, > > > I don't know if this is the right mailing list, but well... > > > How can I mount something with my perl script? > I've got always the error: mount: only root can do this > > > So I changed my script something like this: > > > #! /usr/bin/perl -w > `su - root -c 'mount -t smbfs -o credentials= // > /'`; > > > If I start the script in the shell as root, it works fine. > > > If I start the script in the shell as some other user, it asked me for the > password. > > > If I start the script in via the Internet- Browser, in the log files it first > asked for the password and after one second it completes to "incorrect > password" > > > How can I change my script to execute the mount command as root > automatically, or to mount something within my perl script??? > > > > > Thanks > > > > > > Regards > > > > > Christian Heiss > > > ___ __ > > LANconcept Moll GmbH > > Benzstrasse 1 > 88074 Meckenbeuren > > Voice: +49 (0) 7542 940 3 - 18 > > Fax:+49 (0) 7542 218 24 > Mobil: +49 (0) 171 80 64 254 > <mailto:[EMAIL PROTECTED]> > visit our website <http://www.datentechnik- moll.de> > > ___ __
DBI->connect_cached not playing with Apache::DBI
An Ima::DBI user recently pointed out that DBI->connect_cached is not using
Apache::DBI like DBI->connect does and DBI->connect_cached has slightly
different semantics from Apache::DBI.
sub connect_cached {
# XXX we expect Apache::DBI users to still call connect()
my ($class, $dsn, $user, $pass, $attr) = @_;
($attr ||= {})->{dbi_connect_method} = 'connect_cached';
return $class->connect($dsn, $user, $pass, $attr);
}
There's a problem with the logic in the comment above. Apache::DBI is
supposed to be transparently used by DBI. So, in effect, there are no
Apache::DBI users. More pragmatically, I write a lot of dual-natured
programs. Stuff that might be run under Apache::Registry or might be
a stand-alone. I like using connect_cached() because I don't have to
store a global $Dbh, but I thought I was getting the performance boosts of
Apache::DBI where applicable.
So I guess the question is, why doesn't DBI->connect_cached just defer to
Apache::DBI->connect?
--
This sig file temporarily out of order.
Re: Getting mod_perl-1.27 & Apache-2.0.39
On Sun, 14 Jul 2002, eric wrote: > I've tried every which way and still can't get mod_perl to compile. > apache 2.x is not supported well at this point You didn't say which SSL you were running, but if it's ben's apache-ssl, this simple set of instructions will work. build and install openssl9.6x (b or c) at least unpack apache_1.3.26 copy apache_1.3.26_ssl_1.48.tgz into apache directory, uppack and run ./FixPatch rm apache/src/Configuration rm apache/src/Configuration.apaci edit apache/src/Configuration.tmpl to enable standard modules you may want that are commented out. Typically that will be something like ... mod_info.o, mod_rewrite.o, mod_so.o libproxy.a now go to the mod perl directory modperl-1.26 or 1.27 Run: perl Makefile.PL \ APACHE_SRC=/usr/src/apache/src \ DO_HTTPD=1 \ USE_APACI=1 \ PREP_HTTPD=1 \ EVERYTHING=1 \ make make test # broken make install This will build modperl and copy the appropriate modules to the apache src directories. Answer YES to the questions asked by script go back to apache directory and run ./configure --with-layout=Apache \ --activate-module=src/modules/perl/libperl.a make make install all done :-) Michael
Re: Propogating Errors / E-Toys
Perrin Harkins wrote:
>
> We've actually discussed this on the list. It has to do with closures.
> Matt gave a presentation about exception handling which covers it and
> shows a workaround. You can see it here:
>
> http://axkit.org/docs/presentations/tpc2001/
Sorry to chime in a little late on this.
But the "Exceptions" slides from the page above are either misleading,
or I am misunderstainding just what exactly leaks in Error.
The slides above show a "BAD" example of Error.pm as:
sub handler {
my $r = shift;
my $count;
try {
# use $count in here...
} catch Error with {
};
}
However, the eToys article doesnt say that this is unsafe. What the
eToys article says is unsafe is code with nested try blocks like this:
my $count;
try {
...
try {
# use $count in *here*
};
};
in other words, if I understand the eToys article correctly, the leaks
only happen if I nest a try block inside another try block. I have
experimented some, and it appears to me that this is in fact the case
($count doesnt get cleaned up if there is a nested try). But as long as
I dont nest try blocks there doesnt appear to be a leak.
Are Matt's slides misleading on this point? Or am I missing something here?
Mike
