Re: [mp2.0] W2000, Apache 2.0.45, mod_perl-2 1.99_09-dev crashes
At 18:35 04.04.2003, Randy Kobes wrote: If this is with ActivePerl 8xx, though, then it may be that there's an incompatibility between modules compiled against Apache 2.0.44 (which the mod_perl ppm package on our site was compiled against) and Apache 2.0.45. The Apache group says that, starting with 2.0.42, they're working at maintaining configuration and module interface compatibility, so in principle upgrading from 2.0.44 to 2.0.45 shouldn't be a problem. But with a combination of Win32 and the relative complexity of mod_perl 2, this compatibility may not have survived I've tried compiling the current cvs mod_perl 2 sources against Apache 2.0.45, but have run into a problem (unrelated to the 2.0.45 upgrade) that hasn't yet been resolved. Given the security fixes for Win32 present in 2.0.45, if you feel uneasy about reverting to 2.0.44, I could make available a mod_perl 2 package based on not-so-current cvs sources compiled against 2.0.45 until the problem in the current cvs version is fixed. Just had another thought... maybe you should indeed recompile mod_perl-2 with the older CVS sources, so I can try it out on Apache 2.0.45, and we can be 100% sure that this is the problem... Maybe the problem really is that the old binaries aren't compatible with the new Apache, but at the moment we just don't know. Trying it out would help. Of course it's not necessary if it means too much effort... it would be interesting though to see if the recompile really does solve the problem. Thank You, Sebastian. -- If You're European, do something for YOUR civil rights: http://www.stop1984.com Stop software patents in the EU! http://swpat.ffii.org
Re: Convert Cookies--HTTP Request Headers?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Saturday 05 April 2003 00:10, Kruse, Matt wrote:
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
4. Pass the request on to the requested resource (a script of some
sort)
You'd need to write PerlHeaderParserHandler for that.
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
Why name NAME to HTTP_NAME? Or do you want the cookie content to appear
in subprocess environment (which has similar naming convention), like
other server variables?
This will help me simulate a Single-Sign-On situation where the
authentication handler passes all authenticated user information to
the resource via headers.
Can anyone help me by either:
1. Giving an outline of what handlers I would want to use, and how
I can write request headers with them
or
The header parse phase would be ideal, since you're parsing headers.
PerlInitHandler is an alias PerlHeaderParserHandler in .htaccess files.
2. Writing some sample code :)
package Your::SSOHandler;
use strict;
use Apache::Constants qw(:common);
use Apache::Cookie;
sub handler {
my $r = shift;
my $in = $r-headers_in;
return DECLINED unless $in-{'Cookie'};
my $cookies = Apache::Cookie-parse($in-{'Cookie'});
return DECLINED unless $cookies{'YourAuthenticationCookie'};
my %values = $cookies{'YourAuthenticationCookie'}-value;
my $env = $r-subprocess_env;
while (my ($key, $value) = each %values) {
my $h_key = 'HTTP_' . uc($key);
$in-{$h_key} = $value;
$env-{$h_key} = $value;
}
return OK;
}
1;
in httpd.conf (or .htaccess), put the following line where approppriate:
PerlModule Your::SSOHandler
PerlHeaderParserHandler Your::SSOHandler
Or something like that. Cutting and pasting may cause parse errors on
incompatible windowing environments :)
NOTES:
1. I'm running Apache 2.0 and mod_perl 2 right now, but I can bump
it down if required
I don't know much about the differences in mod_perl 1 vs 2. These
handlers work at least for Apache/mod_perl 1.
2. I've already used mod_headers to simulate this, but
unfortunately that isn't dynamic enough for testing, ie, I need to
change httpd.conf and re-start the server to test different header
scenarios.
For testing you could make the handler module stat and evaluate contents
of an external Perl file. Put your code on the file to be evaluated,
and avoid restarts.
Or simply sending SIGUSR1 to the Apache parent process should be enough
for it to restart child processes and reread configuration.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE+jp7eWD8Ca88cV68RAuBAAJ9u0KWd2bAsHrYes/DXtareCYi00gCgkIEC
o8OTRNmghIHRUhJZAqX+gbs=
=YCIq
-END PGP SIGNATURE-
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
Re: stopping concurrent logins
Todd White [EMAIL PROTECTED] writes: i'm sure this is not a novel need, but i have failed to find or come up with just yet any (non-cookie) solution yet. i'm trying dearly to avoid cookies, but if that's the best or only way to do this, feel free to speak up. i'd love to hear from someone who has already tackled the problem of stopping concurrent web logins to a protected web space. realizing that ultimately people can share their username/password to a for-fee protected web site, we would at *least* like to avoid the possibility that two people could both be logged in at the same time from two different computers. the use of IP address doesn't seem adequate since many users come through a router/proxy running NAT. Hmm, as people are logged in, there must be some kind of session. So the only thing you need is to make sure that there can be at most one session for given user id - in fact, to invalidate any 'older' session(s) while logging in in the 'new' one. -- ( Marcin Kasperski | In any large change, 1/3 will think it is great, 1/3 ) ( http://www.mk.w.pl | will think it is stupid, and 1/3 will wait (Reed) ) () ( Porady dla programisty Oracle: http://www.mk.w.pl/porady/porady_oracle )
