[mp2] UN-bug!

[Beau E. Cox]

Hi Stas and guys -

As of Sat May 31 08:38:30 UTC 2003

1) I have the following installed and tested:

   Server Version: Apache/2.0.46 (Unix) 
   mod_perl/1.99_10-dev (CVS)
   Perl/v5.8.0
   mod_ssl/2.0.46
  OpenSSL/0.9.7b

2) Everything is looking good!

3) GOOD JOB FOLKS...

Aloha => Beau;

Re: trouble with using $r->lookup_uri()

[Aaron Ross]

> my $uri = $r->uri;
> my $subr = $r->lookup_uri($uri);

Is this recursing? the subrequest will run all phases but the content
handler, so
i would think you'll need to add

return unless $r->is_main();

or something like it at the beginning of the routine.

-- Aaron

Re: unsubscribe request

[Kee Hinckley]

At 5:00 PM -0300 5/30/03, Diego Thomas wrote:
remove me from this fuckin list plss
At 5:00 PM -0300 5/30/03, Diego Thomas wrote:
X-Msgfire: MAIL https://www.messagefire.com/member/report.html?id=568519
Return-Path: <[EMAIL PROTECTED]>
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
list-help: 
list-unsubscribe: 
list-post: 
Delivered-To: mailing list [EMAIL PROTECTED]
From: "Diego Thomas" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: unsubscribe request
Date: Fri, 30 May 2003 17:00:13 -0300
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-Virus-Scanned: by AMaViS 0.3.12
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
--
Kee Hinckley
http://www.messagefire.com/  Anti-Spam Service for your POP Account
http://commons.somewhere.com/buzz/   Writings on Technology and Society
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

Re: variable sharing

[Perrin Harkins]

On Fri, 2003-05-30 at 17:46, Arshavir Grigorian wrote:
> Is it possible that calling undef on a global hash in one Apache process 
> not reset the value/contents of the same hash
> in other Apache processes?

I don't quite understand the wording of your question, but the short
answer is that nothing is truly shared between processes.  Copy-on-write
provides some optimization of memory usage at the OS level, but it does
not affect actual sharing.  If you write to a variable in one process,
no other process will be affected, even if it has the same global
variable.

> I am using Apache::Status to examine the content of a specific hash and 
> depending on which Apache process handles my
> request, I get a different value for a specific key in the hash.

Right, modifications to the hash are not shared.

> On a related note, does running several virtual hosts of off the same 
> source tree mean that all global variables are shared
> among all the vhosts?

Virtual hosts are irrelevant.  All that matters is if the code is
running in the same process.

- Perrin

variable sharing

[Arshavir Grigorian]

Hello,

The answer to the question that I am about to ask is "no" (I think) but 
I would just like to make sure.

Is it possible that calling undef on a global hash in one Apache process 
not reset the value/contents of the same hash
in other Apache processes?

I am using Apache::Status to examine the content of a specific hash and 
depending on which Apache process handles my
request, I get a different value for a specific key in the hash.

On a related note, does running several virtual hosts of off the same 
source tree mean that all global variables are shared
among all the vhosts?

Thanks in advance.

Arsh

Re: Stacked Handlers Location directive -- inside and outside virtualhost

[Shashank Kailash Shringi]

Hi There,
I read the following thread (with Geoff's comment in there too):
http://www.gossamer-threads.com/archive/mod_perl_C1/docs-dev_F5/a_little_feedback_P38941/
than I thought about Geoff's advice about using PerlAccess Handler and
came
up with this concoction (which works :-) )

Conf entry:

AuthName someauth
AuthType someauth
PerlAccessHandler Apache::MyModule
PerlAuthenHandler Apache::SuperAuthen
PerlAuthzHandler Apache::Xdoc
require valid-user

--
package Apache::SuperAuthen;

use Apache::Constants qw(:common);
use Apache::Registry ();
use Apache::InHouseModule;
use Apache::MyModule;

sub handler {
my $r = shift;
if (Apache::MyModule::handler($r) == OK ||
Apache::InHouseModule::handler($r) == OK){
return OK;
}

return AUTH_REQUIRED;
}
1;
__END__
---
However, I would be please if someone can explain what actually happens. I
dont "clearly" understand why it works :--)

Thanks,

Shashank.

On Fri, 30 May 2003, Geoffrey Young wrote:

>
> > When http://www.abc.com/~xyz gets called PerlAuthenHandler MyModule is
> > invoked. MyModule code checks for IP after reading a file from xyz
> > directory.
> > If the host ip matches with the one in the file, it returns OK and the
> > PerlAuthzHandler never gets called and the webpage is served to the user.
>
> you may want to try using a PerlAccessHander for checking the IP, then
> combine that with Satisfy Any (as opposed to the Satisfy All default).
>
> HTH
>
> --Geoff
>

Re: Stacked Handlers Location directive -- inside and outside virtualhost

[Shashank Kailash Shringi]

I tried that already. When I use PerlAccessHander with Satisfy Any, the
webpage is always served even if IP check fails. Interestingley, when IP
check fails, it redirects (https url) but never ask for any userid or
password and straight away serves the page.

--
Shashank

On Fri, 30 May 2003, Geoffrey Young wrote:

>
> > When http://www.abc.com/~xyz gets called PerlAuthenHandler MyModule is
> > invoked. MyModule code checks for IP after reading a file from xyz
> > directory.
> > If the host ip matches with the one in the file, it returns OK and the
> > PerlAuthzHandler never gets called and the webpage is served to the user.
>
> you may want to try using a PerlAccessHander for checking the IP, then
> combine that with Satisfy Any (as opposed to the Satisfy All default).
>
> HTH
>
> --Geoff
>

unsubscribe request

[Diego Thomas]

remove me from this fuckin list plss

- Original Message - 
From: "Geoffrey Young" <[EMAIL PROTECTED]>
To: "Shashank Kailash Shringi" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, May 30, 2003 5:00 PM
Subject: Re: Stacked Handlers Location directive -- inside and outside
virtual host


>
> > When http://www.abc.com/~xyz gets called PerlAuthenHandler MyModule is
> > invoked. MyModule code checks for IP after reading a file from xyz
> > directory.
> > If the host ip matches with the one in the file, it returns OK and the
> > PerlAuthzHandler never gets called and the webpage is served to the
user.
>
> you may want to try using a PerlAccessHander for checking the IP, then
> combine that with Satisfy Any (as opposed to the Satisfy All default).
>
> HTH
>
> --Geoff
>

Re: Stacked Handlers Location directive -- inside and outside virtualhost

[Geoffrey Young]

When http://www.abc.com/~xyz gets called PerlAuthenHandler MyModule is
invoked. MyModule code checks for IP after reading a file from xyz
directory.
If the host ip matches with the one in the file, it returns OK and the
PerlAuthzHandler never gets called and the webpage is served to the user.
you may want to try using a PerlAccessHander for checking the IP, then 
combine that with Satisfy Any (as opposed to the Satisfy All default).

HTH

--Geoff

Re: mod_perl caching form data?

[David Ressman]

Thus spake Perrin Harkins ([EMAIL PROTECTED]):
> Let's not jump to conclusions.  We don't have a test case yet, and no
> one has seen David's code so he might have a simple global variables
> problem.

I suspect that the more likely explanation of this particular problem
is that I goofed up.  Anyway, the script is a thousand or so lines
long, so it doesn't make a whole lot of sense to post it here.  I'll go
through it all with a fine-toothed comb and try to see if I can make
the problem go away without having to call delete() to wipe out the
parameters.

If I'm able to do it, I'll certainly send something back to the list.

Stacked Handlers Location directive -- inside and outside virtualhost

[Shashank Kailash Shringi]

I try to do the following:
Outside the virtual host (non-ssl) in the location directive, I have the
following:

AuthName someauth
AuthType sometype
PerlAuthenHandler MyModule
require valid-user


When http://www.abc.com/~xyz gets called PerlAuthenHandler MyModule is
invoked. MyModule code checks for IP after reading a file from xyz
directory.
If the host ip matches with the one in the file, it returns OK and the
PerlAuthzHandler never gets called and the webpage is served to the user.

However, if the IP check fails, the user is redirected to another
PerlAuthenHandler (which is our InHouse Authentication module) called
InHouseModule. This redirection is done over ssl and thus is user is
redirected to https://www.abc.com/~xyz which invokes PerlAuthenHandler
InHouseModule. For this there needs to be an entry for PerlAuthenHandler
InHouseModule inside virtual host like so:


AuthName someauth
AuthType sometype
PerlAuthenHandler InHouseModule
PerlAuthzHandler MyModule
require valid-user



Thus the user is asked for netid and password and if the authentication is
successful via InhouseModule PerlAuthzHandler MyModule gets called again
to do some more check by reading file.

My problem is this:
Everything works fine if I have the above two entries in the conf file.
However, we need one single entry in access.conf so that we dont end up
adding the Location directive (both inside and outside) for every URL
(last count there were 250
users) and using IF condition it gets loaded in Location directive both
inside and outside virtual host. Essentially we need one common entry like
this in access.conf:

AuthName someauth
AuthType sometype
PerlAuthenHandler MyModule
PerlAuthenHandler InHouseModule
PerlAuthzHandler MyModule
require valid-user


But this doesnt work when PerlAuthenHandler MyModule returns OK (i.e
when IP
check is successful). Probably
becoz it still tries to invoke the second PerlAuthenHandler InHouseModule
or maybe two PerlAuthenHandler in one location directive in itself is not
the right thing to do.

Then I find out about stacked_handlers and try to make this common entry
work:

AuthName someauth
AuthType sometype
PerlAuthenHandler MyModule
PerlAuthzHandler MyModule
require valid-user


Basically take off PerlAuthenHandler InHouseModule from conf file and use
$r->push_handlers( "PerlAuthenHandler", "Apache::Bluestem" );
in the PerlAuthenHandler MyModule code when it tries to do the REDIRECT
(after failing IP check and before proceeding for other checks
authenticating the user netid and password).
I get an internal server error.

Where am I going wrong? I hope I have explained myself clearly.
Is there any other way of doing this?
Thanks for help.

--
Shashank.

trouble with using $r->lookup_uri()

[Ryan Muldoon]

I'm trying to write a authentication handler using mod_perl, and am
encountering some difficulty.  I have isolated my problem to the usage
of the lookup_uri($uri) function call - whenever I call it, my module
segfaults.  I have tested the input with both a variable string, and
just a quoted string, and get the same result.

My module is as follows:

package Apache::AuthNx509;

use strict;
use Apache::Constants qw(:common);
use Text::ParseWords  qw(quotewords);
use Apache::Log ();

sub handler {
my $r = shift;
my $c = $r->connection;
my $log = $r->log;

my $certcomponent = $r->dir_config('CertComponent') ||
'SSL_CLIENT_S_DN_O';
my $certcompvalue = $r->dir_config('CertComponentValue') ||
'University of Wisconsin';
my $usercomponent = $r->dir_config('RemoteUserCertComponent') ||
'SSL_CLIENT_S_DN_CN';
 
my $uri = $r->uri;
my $subr = $r->lookup_uri($uri);
my $apachecertcomp = $subr->subprocess_env($certcomponent);
$log->notice("hello: $apachecertcomp");
   if ($apachecertcomp eq $certcompvalue)
{
$log->notice("$certcompvalue good");
$c->user = $r->subprocess_env->{$usercomponent};
$log->notice("$c->user logged in successfully");
return OK;
}
$log->notice("cert no good: $r->subprocess_env->{$certcomponent}");
my $reason = "Client Cert not in correct form";
$r->note_basic_auth_failure;
$r->log_reason($reason, $r->filename);
return DECLINED;
}

1;
__END__

If I change
 my $subr = $r->lookup_uri($uri);
to
 my $subr = $r;
my program does not segfault, though I am unable to get access to the
apache table.  

If anyone has any ideas on how to fix this problem, or knows of another
way to get access to environment variables (provided by mod_ssl), I
would be very interested.  Thanks!

--Ryan

Re: mod_perl caching form data?

[Perrin Harkins]

On Fri, 2003-05-30 at 10:42, Randal L. Schwartz wrote:
> I had been using CGI.pm (through Template::Plugin::CGI), and was
> mystified because *occasionally* the wrong picture would show, but a
> simple reload fixed it.
> 
> I fixed the bug by avoiding CGI.pm, and using Apache::Template's
> "param" variable directly instead.
> 
> So maybe there is a CGI.pm bug with regarding to clearing out the
> values in a mod_perl environment.  I wonder how simple of a test we
> can concoct to determine that?

Let's not jump to conclusions.  We don't have a test case yet, and no
one has seen David's code so he might have a simple global variables
problem.

Many people are using CGI.pm successfully with mod_perl, so if there's a
problem it only happens in specific circumstances.  If someone has a
test case, by all means, post it.

- Perrin

Combining ScriptAlias with Perl handler in VirtualHosts

[Eugene Miretskiy]

Is it ok to run a /cgi-bin/ ScriptAlias directory for mod_cgi in the
same 
VirtualHost that ModPerl::Registry is also handling a /perl/ directory 
for?  It seems to work ok for the first 10 or 20 vhosts, but 
mod_perl breaks after 30 or 40 entries.  This is an example of what I'm
doing:



ServerAdmin [EMAIL PROTECTED]
DocumentRoot /web/webname/htdocs
ServerName webname.domain.com


 Options FollowSymLinks Includes Indexes


#   Will use mod_perl

Alias /perl/ "/web/webname/perl/"

SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI


ScriptAlias /cgi-bin/ "/web/webname/cgi-bin/"

ErrorLog "|/apps/cronolog/1.6.2/sbin/cronolog -S 
/web/webname/logs/error
_log -P /web/webname/logs/error_log.previous 
/web/webname/logs/error_log.%Y.wk%W"

CustomLog "|/apps/cronolog/1.6.2/sbin/cronolog -S 
/web/webname/logs/acce
ss_log -P /web/webname/logs/access_log.previous 
/web/webname/logs/access_log.%Y.wk
%W" common

CustomLog "|/apps/cronolog/1.6.2/sbin/cronolog -S 
/web/webname/logs/refe
rer_log -P /web/webname/logs/referer_log.previous 
/web/webname/logs/referer_log.%Y
.wk%W" referer

CustomLog "|/apps/cronolog/1.6.2/sbin/cronolog -S 
/web/webname/logs/agen
t_log -P /web/webname/logs/agent_log.previous 
/web/webname/logs/agent_log.%Y.wk%W"
 agent

Re: how to make sure code wasn't changed

[Randal L. Schwartz]

> "Mike" == Mike Zelina <[EMAIL PROTECTED]> writes:

Mike> Here's my question: has anyone setup a clever way, possibly
Mike> using CRC/MD5 analysis, to check to make sure code hasn't been
Mike> changed?  I don't care if someone steals it or gives it to their
Mike> friends, but I don't want the code to yield results if it's been
Mike> modified - either intentionally or on accident - because it
Mike> could give false results.  These are sales guys machines which
Mike> (no offense to any sales people lurking on this list) means
Mike> anything can and probably will happen.  I realize that someone
Mike> could circumvent a CRC check just by changing the CRC check
Mike> number, but I'm not worried...  if they are that clever kudos to
Mike> them.

And are you also providing a way to set up those MD5s so that maintenance
can be performed by someone other than you if you get hit by a bus?

If not, then I'd not be paying you one dime if you were my vendor.

You make yourself irreplacable by providing a good product at a fair
price, not by holding your customer hostage so that they can only get
support through you.

This is the creed and core philosophy of open source.  Do not stand on
the shoulders of the giants who have gone before you and drool onto
their face.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: mod_perl caching form data?

[Randal L. Schwartz]

> "Perrin" == Perrin Harkins <[EMAIL PROTECTED]> writes:

Perrin> On Thu, 2003-05-29 at 17:26, [EMAIL PROTECTED] wrote:
>> A simple $cgi->delete('ipaddress') to delete the value when I create
>> the field has done the trick.  Thanks very much to the both of you.

Perrin> I'm glad to hear that worked, but it's still worrisome that you were
Perrin> seeing data leak between different users.  The form widgets are only
Perrin> supposed to be sticky for values submitted on the current request.  It
Perrin> indicates either a bug in the way CGI.pm clears its variables under
Perrin> mod_perl or a bug in your script that could surface again later.


OK, throwing my hat into the ring here...

maybe *I* wasn't hallucinating then.  I just had a recent
fix to a longstanding bug in the picture section of my website...

I had been using CGI.pm (through Template::Plugin::CGI), and was
mystified because *occasionally* the wrong picture would show, but a
simple reload fixed it.

I fixed the bug by avoiding CGI.pm, and using Apache::Template's
"param" variable directly instead.

So maybe there is a CGI.pm bug with regarding to clearing out the
values in a mod_perl environment.  I wonder how simple of a test we
can concoct to determine that?

Lincoln, are you listening?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: Help with Apache::httpd_conf

[Ged Haywood]

Hi there,

On Thu, 29 May 2003, Shashank Kailash Shringi wrote:

> I need one common entry for handlers in Location directive, both
> inside and outside virtual host.

I'm not sure I understand your problem, but I wonder if it's the sort
of thing that mod_macro could help you with?

73,
Ged.

Re: mod_perl caching form data?

[Dale Lancaster]

This appears to be the classic "global variable/uninitialized variable"
issue with your script.  Mod_perl will load that script once and never
reload it again unless you tell it too, even when different users access
that script.  If you have written a CGI script that doesn't lead itself to a
ready rewrite to run under mod_perl, try running it under the "PerlRun" mode
of mod_perl, it works great for this situation.

Go here to read up on the issue:
http://perl.apache.org/docs/1.0/guide/porting.html#Sometimes_it_Works__Sometimes_it_Doesn_t

dale

- Original Message - 
From: "David Ressman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 29, 2003 1:19 PM
Subject: mod_perl caching form data?


> Hi all,
>
> I'm having a problem with mod_perl 1.2.7 that's baffling me completely,
> and I've been searching and reading for days, but I still can't figure
> it out.  My apologies if this comes up frequently.  I did try rather
> lengthy searches through the mailing list archives.
>
> Right now, I'm using mod_perl 1.2.7 compiled into an apache 1.3.27
> server running on a Solaris 9 (semi-current patches, though I can't
> imagine that that's relevant) server.  I've written some fairly
> straight-forward mod_perl scripts (using CGI.pm).  They take form
> data from the user, process it, and stick it in a database (through
> DBI).
>
> So far, so good.  Everything works pretty well...  Except that
> something's caching previously entered form data and displaying it back
> to me as the default values in those same forms.  As an example, this
> form has a text field that asks for IP addresses, and the text input
> will occasionally be filled out with the IP address of a system that
> you had entered a few minutes ago.
>
> Naturally, I suspected that my browser was the guilty party, even
> though I had specified '-1d' as the expiration time in the CGI header()
> command.  It turns out that this is not the case.  The forms will
> occasionally be pre-filled out with IP addresses that other people have
> given!  I even went so far as to set up a network sniffer to verify
> that the server was indeed setting (in the HTML it sent to the client)
> the "value" parameter of the text fields to an IP address that another
> user had previously entered.
>
> Needless to say, my script is *not* setting the "default" or "value"
> parameters for these text fields.  As an uneducated guess, I'd say that
> each httpd child-process is automatically filling out forms with data
> that it itself has previously received, but that's only a guess, and it
> still doesn't get me any closer to figuring out why it's happening.
>
> Can anyone offer any assistance or point me somewhere that I could find
> some documentation on what's happening?  I'm completely baffled.
>
> Thanks!
>
> David