Re: how to make sure code wasn't changed

2003-05-31 Thread Patrick Mulvany
On Thu, May 29, 2003 at 06:02:10PM -0700, Mike Zelina wrote:
 Here's my question:  has anyone setup a clever way, possibly using CRC/MD5 analysis,
 to check to make sure code hasn't been changed?  I don't care if someone steals it or
 gives it to their friends, but I don't want the code to yield results if it's been 
 modified - either
 intentionally or on accident - because it could give false results.

Some time ago I was experimenting with a PerlTransHandler that did an MD5 digest of 
the called URL and used that as the translated file name. People tend not to play 
around with code if they are not even sure what script is which.

Hope that helped

Paddy


Re: mod_perl caching form data?

2003-05-31 Thread 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



Re: Help with Apache::httpd_conf

2003-05-31 Thread 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?

2003-05-31 Thread 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] URL: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: how to make sure code wasn't changed

2003-05-31 Thread 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] URL: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!


Combining ScriptAlias with Perl handler in VirtualHosts

2003-05-31 Thread 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:

VirtualHost ###.###.##.##

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

Directory /web/webname/htdocs
 Options FollowSymLinks Includes Indexes
/Directory

#   Will use mod_perl

Alias /perl/ /web/webname/perl/
Location /perl/
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
/Location

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

/VirtualHost



Re: mod_perl caching form data?

2003-05-31 Thread 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


trouble with using $r-lookup_uri()

2003-05-31 Thread 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


Stacked Handlers Location directive -- inside and outside virtualhost

2003-05-31 Thread Shashank Kailash Shringi
I try to do the following:
Outside the virtual host (non-ssl) in the location directive, I have the
following:
Location /~xyz
AuthName someauth
AuthType sometype
PerlAuthenHandler MyModule
require valid-user
/Location

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:
virtual host
Location ~xyz
AuthName someauth
AuthType sometype
PerlAuthenHandler InHouseModule
PerlAuthzHandler MyModule
require valid-user
/Location
/virtual host

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:
Location ~xyz
AuthName someauth
AuthType sometype
PerlAuthenHandler MyModule
PerlAuthenHandler InHouseModule
PerlAuthzHandler MyModule
require valid-user
/Location

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:
Location ~xyz
AuthName someauth
AuthType sometype
PerlAuthenHandler MyModule
PerlAuthzHandler MyModule
require valid-user
/Location

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.


Re: mod_perl caching form data?

2003-05-31 Thread 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.



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

2003-05-31 Thread 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



unsubscribe request

2003-05-31 Thread 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

2003-05-31 Thread 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



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

2003-05-31 Thread 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:
Location /~xyz
AuthName someauth
AuthType someauth
PerlAccessHandler Apache::MyModule
PerlAuthenHandler Apache::SuperAuthen
PerlAuthzHandler Apache::Xdoc
require valid-user
/Location
--
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



variable sharing

2003-05-31 Thread 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: variable sharing

2003-05-31 Thread 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


Re: unsubscribe request

2003-05-31 Thread 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: mailto:[EMAIL PROTECTED]
list-unsubscribe: mailto:[EMAIL PROTECTED]
list-post: mailto:[EMAIL PROTECTED]
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: trouble with using $r-lookup_uri()

2003-05-31 Thread 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




[mp2] UN-bug!

2003-05-31 Thread 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;