Re: getting *any* variables out of the server environment
On Mon, 2003-06-09 at 15:24, Perrin Harkins wrote:
> [ Please keep it on the list. ]
>
Sorry about that!
> On Mon, 2003-06-09 at 16:12, Ryan Muldoon wrote:
> > > Ryan, can you post a more complete code example?
> > >
> > > - Perrin
> > Here it is:
> >
> > 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;
> > return OK unless $r->is_main;
> >
> > 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 $cn = $r->subprocess_env('MOD_PERL');
> > # $log->notice("test: $ENV{'MOD_PERL'}");
> > my $apachecertcomp = $r->subprocess_env{$certcomponent};
>
> That should be $r->subprocess_env($certcomponent). It's a method, not a
> hash key. Also, put the lookup_uri stuff back in, since it seems that
> you need it when trying to get the stuff from mod_ssl.
>
> - Perrin
I must have been stupid. Making those two corrections, everything works
(Almost)! Right now it is failing on my attempts to set the user
variable (I want to be able to set REMOTE_USER to an arbitrary cert
field). I'll have to dig a bit to figure out how to do that. Thank you
everyone on the list for helping me out so much today - I really
appreciate it. Many days of hair-pulling are at an end. ;-)
--Ryan
Re: getting *any* variables out of the server environment
Actually, upon flushing my browser cache and checking again, I can in fact read the MOD_PERL environment variable just fine. But still no luck on any mod_ssl related variables. --Ryan
Re: getting *any* variables out of the server environment
On Mon, 2003-06-09 at 14:35, Geoffrey Young wrote:
> Ryan Muldoon wrote:
> > Geoffrey,
> >
> > Thanks for the explanation. Unfortunately, I think I am still a little
> > unclear as to how to proceed. If I understand you correctly, my first
> > method is completely wrongheaded.
>
> :)
>
> > (I tried this because it is how the
> > "Writing Apache Modules with Perl and C" does it. p.327)
>
> don't have my book handy to check that.
>
> > So it sounds
> > like the second way is the appropriate usage for subprocess_env(). But
> > it seems like you're saying that I shouldn't be using that at all.
>
> no, I wasn't saying that :) subprocess_env() from the main request is the
> right way to go. I was just trying to let you know that it has nothing to
> do with %ENV really.
>
Ok, cool. Thanks for the clarification ;-)
> > Specifically, here is what I'd like to get out of the environment:
> > SSL_CLIENT_S_DN_CN
> > SSL_CLIENT_S_DN_O
> > and things of that nature.
>
> ok, those are definitely setup in the subprocess_env table according to the
> code I just took a look at. however...
>
> > According to mod_ssl's documentation, these
> > are put in ENV upon processing of a client certificate.
>
> from what I can see, that's not entirely true. they are set in
> subprocess_env where they sit and wait, presumably for somebody else to call
> add_cgi_vars since mod_ssl does not (but mod_cgi and mod_perl both do).
>
> the problem you're seeing is that these variables are setup during the fixup
> phase, so in using a PerlAuthenHandler you're trying to see them too early.
>
> int ssl_hook_Fixup(request_rec *r)
> {
> SSLSrvConfigRec *sc = mySrvConfig(r->server);
> SSLDirConfigRec *dc = myDirConfig(r);
> table *e = r->subprocess_env;
> ...
> /*
> * Annotate the SSI/CGI environment with standard SSL information
> */
> /* the always present HTTPS (=HTTP over SSL) flag! */
> ap_table_set(e, "HTTPS", "on");
> /* standard SSL environment variables */
> if (dc->nOptions & SSL_OPT_STDENVVARS) {
> for (i = 0; ssl_hook_Fixup_vars[i] != NULL; i++) {
> var = (char *)ssl_hook_Fixup_vars[i];
> val = ssl_var_lookup(r->pool, r->server, r->connection, r, var);
> if (!strIsEmpty(val))
> ap_table_set(e, var, val);
> }
> }
>
> in other words, you're SOL from the current request. perhaps this is why
> the eagle book said to get them from a subrequest - presumably the
> subrequest would have them, since it runs through the fixup phase and SSL
> stuff is per-connection and not per-request.
>
Yeah, I think that was the motivation. On the upside of my current
difficulty, I'm getting to learn a lot more about how apache does
things.
> > Ideally, I'd
> > like to make which fields to extract configurable, so I don't want to
> > hard-code.
> >
> > Currently, I have
> > PerlPassEnv SSL_CLIENT_S_DN_O
> > PerlPassEnv SSL_CLIENT_S_DN_CN
> > in my httpd.conf, but it doesn't seem to make any kind of difference.
>
> don't do that. PerlPassEnv is for passing variables such as those from
> /etc/profile to the %ENV of the Apache child processes.
>
Ok, removed. Thank you very much for the in-depth replies. It is very
useful. Unfortunately any variable-reading continues to elude me. But
I really appreciate all the help!
--Ryan
Re: getting *any* variables out of the server environment
>From what I understand, what you outline *should* work. It just doesn't
for me for some reason. I really appreciate everyone's help though.
(And as an aside - I learned how to program in Perl from your books -
many thanks)
--Ryan
On Mon, 2003-06-09 at 14:23, Randal L. Schwartz wrote:
> >>>>> "Ryan" == Ryan Muldoon <[EMAIL PROTECTED]> writes:
>
> Ryan> Geoffrey,
> Ryan> Thanks for the explanation. Unfortunately, I think I am still a little
> Ryan> unclear as to how to proceed. If I understand you correctly, my first
> Ryan> method is completely wrongheaded. (I tried this because it is how the
> Ryan> "Writing Apache Modules with Perl and C" does it. p.327) So it sounds
> Ryan> like the second way is the appropriate usage for subprocess_env(). But
> Ryan> it seems like you're saying that I shouldn't be using that at all.
> Ryan> Specifically, here is what I'd like to get out of the environment:
> Ryan> SSL_CLIENT_S_DN_CN
> Ryan> SSL_CLIENT_S_DN_O
> Ryan> and things of that nature. According to mod_ssl's documentation, these
> Ryan> are put in ENV upon processing of a client certificate. Ideally, I'd
> Ryan> like to make which fields to extract configurable, so I don't want to
> Ryan> hard-code.
>
> Well, then, in any handler after the mod_ssl has run, you
> should be be able to use $r->subprocess_env("SSL_CLIENT_S_DN_CN")
> to get at that info.
>
> Ryan> Currently, I have
> Ryan> PerlPassEnv SSL_CLIENT_S_DN_O
> Ryan> PerlPassEnv SSL_CLIENT_S_DN_CN
> Ryan> in my httpd.conf, but it doesn't seem to make any kind of difference.
> Ryan> To make sure it isn't just mod_ssl being lame for some reason, I've
> Ryan> tried it with DOCUMENT_ROOT and other standard ENV variables. But to no
> Ryan> avail. :(
>
> That takes the enviroment variables that apache was started with
> and passes those to mod_perl. Probably not what you want.
>
> (I'm doing this from memory, so please correct me if I'm wrong.)
Re: getting *any* variables out of the server environment
I'm trying to do this as a PerlAuthenHandler, so it should be well past
mod_ssl's involvement, but before the fixup stage. Trying to print out
MOD_PERL either through a subprocess or ENV fails. So maybe I'm in
bigger trouble than I thought?
--Ryan
On Mon, 2003-06-09 at 14:26, Issac Goldstand wrote:
> Ryan,
> Ust out of curiosity, at what stage in the request chain are you doing
> this? If you are doing anything before mod_ssl populates its environment
> variables (which I seem to rembmer being at Fixup, although I may be
> confusing with something else), you wouldn't be able to access them. You
> *should* still be able to get to other Apache environment variables.
> Try an easy one: test for mod_perl. If that works, your environment
> variables are OK, and it's likely a mod_ssl problem that you're having.
>
> Issac
>
> - Original Message -
> From: "Ryan Muldoon" <[EMAIL PROTECTED]>
> To: "Geoffrey Young" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Monday, June 09, 2003 10:13 PM
> Subject: Re: getting *any* variables out of the server environment
>
>
> > Geoffrey,
> >
> > Thanks for the explanation. Unfortunately, I think I am still a little
> > unclear as to how to proceed. If I understand you correctly, my first
> > method is completely wrongheaded. (I tried this because it is how the
> > "Writing Apache Modules with Perl and C" does it. p.327) So it sounds
> > like the second way is the appropriate usage for subprocess_env(). But
> > it seems like you're saying that I shouldn't be using that at all.
> > Specifically, here is what I'd like to get out of the environment:
> > SSL_CLIENT_S_DN_CN
> > SSL_CLIENT_S_DN_O
> > and things of that nature. According to mod_ssl's documentation, these
> > are put in ENV upon processing of a client certificate. Ideally, I'd
> > like to make which fields to extract configurable, so I don't want to
> > hard-code.
> >
> > Currently, I have
> > PerlPassEnv SSL_CLIENT_S_DN_O
> > PerlPassEnv SSL_CLIENT_S_DN_CN
> > in my httpd.conf, but it doesn't seem to make any kind of difference.
> > To make sure it isn't just mod_ssl being lame for some reason, I've
> > tried it with DOCUMENT_ROOT and other standard ENV variables. But to no
> > avail. :(
> >
> > --Ryan
> >
> > On Mon, 2003-06-09 at 13:59, Geoffrey Young wrote:
> > > Ryan Muldoon wrote:
> > > > I'm not able to get *any* variables out from the apache server
> > > > environment.
> > >
> > > ok, first off, this is a two step process for Apache. the first step is
> > > that modules (like mod_ssl) populate the subprocess_env table with
> various
> > > values. then, modules like mod_cgi and mod_perl come along and populate
> > > %ENV with the values from subprocess_env as well as various other CGI
> > > specific variables (like DOCUMENT_ROOT or whatever else there is). the
> > > point is that you're really not after environment variables if you want
> to
> > > test for something like $r->subprocess_env('HTTPS') - that it ends up as
> > > $ENV{HTTPS} is a byproduct of modules like mod_cgi and mod_perl.
> > >
> > > just for your own edification :)
> > >
> > > > As you might be able to imagine, this is extremely
> > > > frustrating, and inhibits my ability to do anything of use with
> > > > mod_perl. My basic technique has been:
> > > > my $uri = $r->uri;
> > > > return unless $r->is_main();
> > > > my $subr = $r->lookup_uri($uri);
> > > > my $apachecertcomp = $subr->subprocess_env($certcomponent);
> > >
> > > I don't understand the need for a subrequest to the same URI -
> > > subprocess_env has nothing to do with an actual subprocess. each
> request
> > > (including subrequests) have their own subprocess_env table attached to
> $r.
> > > in many cases, modules are coded to behave differently for subrequests
> > > than for the main request, so something you may see in
> $r->subprocess_env()
> > > could not be in $r->lookup_uri($uri)->subprocess_env().
> > >
> > > > But this doesn't work. I also tried
> > > > my $var = $r->subprocess_env("VARIABLE_NAME");
> > > > And this does not work either. I really need to be able to use
> > > > environment variables that mod_ssl sets in my authentication handler.
> > >
> > > a few things here too. for the reasons described above,
> subprocess_env() is
> > > not a substitute for %ENV, so if what you want is a true %ENV value
> (such as
> > > those from PerlPassEnv), you will not be able to get to it via
> > > $r->subprocess_env().
> > >
> > > > Any ideas? Thanks!
> > >
> > > HTH
> > >
> > > --Geoff
> > >
> > >
> > >
> >
>
Re: getting *any* variables out of the server environment
I didn't. But I just set that, and it didn't seem to make a difference --Ryan On Mon, 2003-06-09 at 14:16, Randy Kobes wrote: > On Mon, 9 Jun 2003, Ryan Muldoon wrote: > > > Geoffrey, > > > > Thanks for the explanation. Unfortunately, I think I am > > still a little unclear as to how to proceed. If I understand > > you correctly, my first method is completely wrongheaded. (I > > tried this because it is how the "Writing Apache Modules with > > Perl and C" does it. p.327) So it sounds like the second way > > is the appropriate usage for subprocess_env(). But it seems > > like you're saying that I shouldn't be using that at all. > > Specifically, here is what I'd like to get out of the > > environment: SSL_CLIENT_S_DN_CN SSL_CLIENT_S_DN_O and things of > > that nature. According to mod_ssl's documentation, these are > > put in ENV upon processing of a client certificate. Ideally, > > I'd like to make which fields to extract configurable, so I > > don't want to hard-code. > > > > Currently, I have > > PerlPassEnv SSL_CLIENT_S_DN_O > > PerlPassEnv SSL_CLIENT_S_DN_CN > > in my httpd.conf, but it doesn't seem to make any kind of difference. > > To make sure it isn't just mod_ssl being lame for some reason, I've > > tried it with DOCUMENT_ROOT and other standard ENV variables. But to no > > avail. :( > > Do you have a >SSLOptions +StdEnvVars > directive inside the relevant location of your httpd.conf?
Re: getting *any* variables out of the server environment
PerlSetEnv works fine. I can't, however, put PerlPassEnv inside either
a Location or Directory block, if that makes any difference. Apache
says it is a configuration error to do so (though PerlSetEnv works
fine).
I've tried every way that I can think of to do
$r->subprocess_env('VARIABLE'), and it definitely does not work. :(
--Ryan
On Mon, 2003-06-09 at 14:04, Perrin Harkins wrote:
> On Mon, 2003-06-09 at 14:49, Ryan Muldoon wrote:
> > I tried that as well (and just re-tried). My understanding is that the
> > %ENV hash only gets updated in the fixup stage, so the mod_ssl
> > environment variables can't be accessed that way. Thanks for the
> > suggestion though!
>
> Okay. And you're certain that a simple $r->subprocess_env('VARIABLE')
> doesn't work? Have you tried setting a variable yourself as a test with
> PerlSetEnv in httpd.conf?
>
> - Perrin
Re: getting *any* variables out of the server environment
Geoffrey,
Thanks for the explanation. Unfortunately, I think I am still a little
unclear as to how to proceed. If I understand you correctly, my first
method is completely wrongheaded. (I tried this because it is how the
"Writing Apache Modules with Perl and C" does it. p.327) So it sounds
like the second way is the appropriate usage for subprocess_env(). But
it seems like you're saying that I shouldn't be using that at all.
Specifically, here is what I'd like to get out of the environment:
SSL_CLIENT_S_DN_CN
SSL_CLIENT_S_DN_O
and things of that nature. According to mod_ssl's documentation, these
are put in ENV upon processing of a client certificate. Ideally, I'd
like to make which fields to extract configurable, so I don't want to
hard-code.
Currently, I have
PerlPassEnv SSL_CLIENT_S_DN_O
PerlPassEnv SSL_CLIENT_S_DN_CN
in my httpd.conf, but it doesn't seem to make any kind of difference.
To make sure it isn't just mod_ssl being lame for some reason, I've
tried it with DOCUMENT_ROOT and other standard ENV variables. But to no
avail. :(
--Ryan
On Mon, 2003-06-09 at 13:59, Geoffrey Young wrote:
> Ryan Muldoon wrote:
> > I'm not able to get *any* variables out from the apache server
> > environment.
>
> ok, first off, this is a two step process for Apache. the first step is
> that modules (like mod_ssl) populate the subprocess_env table with various
> values. then, modules like mod_cgi and mod_perl come along and populate
> %ENV with the values from subprocess_env as well as various other CGI
> specific variables (like DOCUMENT_ROOT or whatever else there is). the
> point is that you're really not after environment variables if you want to
> test for something like $r->subprocess_env('HTTPS') - that it ends up as
> $ENV{HTTPS} is a byproduct of modules like mod_cgi and mod_perl.
>
> just for your own edification :)
>
> > As you might be able to imagine, this is extremely
> > frustrating, and inhibits my ability to do anything of use with
> > mod_perl. My basic technique has been:
> > my $uri = $r->uri;
> > return unless $r->is_main();
> > my $subr = $r->lookup_uri($uri);
> > my $apachecertcomp = $subr->subprocess_env($certcomponent);
>
> I don't understand the need for a subrequest to the same URI -
> subprocess_env has nothing to do with an actual subprocess. each request
> (including subrequests) have their own subprocess_env table attached to $r.
> in many cases, modules are coded to behave differently for subrequests
> than for the main request, so something you may see in $r->subprocess_env()
> could not be in $r->lookup_uri($uri)->subprocess_env().
>
> > But this doesn't work. I also tried
> > my $var = $r->subprocess_env("VARIABLE_NAME");
> > And this does not work either. I really need to be able to use
> > environment variables that mod_ssl sets in my authentication handler.
>
> a few things here too. for the reasons described above, subprocess_env() is
> not a substitute for %ENV, so if what you want is a true %ENV value (such as
> those from PerlPassEnv), you will not be able to get to it via
> $r->subprocess_env().
>
> > Any ideas? Thanks!
>
> HTH
>
> --Geoff
>
>
>
RE: getting *any* variables out of the server environment
I'm using mod_perl 1. But I'm setting the handlers in httpd.conf. I
sent a message to the list on thursday ("problem with pulling variables
from mod_ssl") that more fully describes my situtation.
--Ryan
On Mon, 2003-06-09 at 14:31, Marc M. Adkins wrote:
> IF you're using mp2...in your httpd.conf are you setting up the handlers
> with modperl or perl-script? The former doesn't provide any environment
> variables:
>
> http://perl.apache.org/docs/2.0/user/config/config.html#C_SetHandler_
>
> I don't believe this applies to mp1.
>
> mma
>
> > -Original Message-
> > From: Ryan Muldoon [mailto:[EMAIL PROTECTED]
> > Sent: Monday, June 09, 2003 11:30 AM
> > To: [EMAIL PROTECTED]
> > Subject: getting *any* variables out of the server environment
> >
> >
> > I'm not able to get *any* variables out from the apache server
> > environment. As you might be able to imagine, this is extremely
> > frustrating, and inhibits my ability to do anything of use with
> > mod_perl. My basic technique has been:
> > my $uri = $r->uri;
> > return unless $r->is_main();
> > my $subr = $r->lookup_uri($uri);
> > my $apachecertcomp = $subr->subprocess_env($certcomponent);
> > But this doesn't work. I also tried
> > my $var = $r->subprocess_env("VARIABLE_NAME");
> > And this does not work either. I really need to be able to use
> > environment variables that mod_ssl sets in my authentication handler.
> > Any ideas? Thanks!
> >
> > --Ryan
> >
>
Re: getting *any* variables out of the server environment
I tried that as well (and just re-tried). My understanding is that the
%ENV hash only gets updated in the fixup stage, so the mod_ssl
environment variables can't be accessed that way. Thanks for the
suggestion though!
--Ryan
On Mon, 2003-06-09 at 13:41, Perrin Harkins wrote:
> On Mon, 2003-06-09 at 14:29, Ryan Muldoon wrote:
> > I'm not able to get *any* variables out from the apache server
> > environment.
>
> Did you try the normal $ENV{'VARIABLE'} approach?
>
> - Perrin
getting *any* variables out of the server environment
I'm not able to get *any* variables out from the apache server
environment. As you might be able to imagine, this is extremely
frustrating, and inhibits my ability to do anything of use with
mod_perl. My basic technique has been:
my $uri = $r->uri;
return unless $r->is_main();
my $subr = $r->lookup_uri($uri);
my $apachecertcomp = $subr->subprocess_env($certcomponent);
But this doesn't work. I also tried
my $var = $r->subprocess_env("VARIABLE_NAME");
And this does not work either. I really need to be able to use
environment variables that mod_ssl sets in my authentication handler.
Any ideas? Thanks!
--Ryan
problem with pulling variables from mod_ssl
I'm trying to write an apache authentication module that uses client
certificates for authentication. Basically, all I'm trying to do is use
what mod_ssl does for cert verification, and then set REMOTE_USER. I
wrote to the list last week about a segfault, which was resolved thanks
to the help you guys gave me. Now I am stuck with a problem that is
likely a logic error on my part, but I have a feeling that my problem
stems from a misunderstanding of how apache is supposed to work. Since
my module is very short, I'll include it in this email, along with the
relevant contents of my error_log, in the hopes that someone might be
able to point me in the right direction. Thanks!
---my module, AuthNx509.pm
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;
return unless $r->is_main();
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__
--
error log data:
Thu Jun 5 14:57:11 2003] [notice] [client 128.104.16.134] hello:
[Thu Jun 5 14:57:11 2003] [notice] [client 128.104.16.134] cert no
good: Apache=SCALAR(0x8100308)->subprocess_env->{SSL_CLIENT_S_DN_C}
[Thu Jun 5 14:57:11 2003] [error] access to /var/www/html/test failed
for 128.104.16.134, reason: Client Cert not in correct form
[Thu Jun 5 14:57:13 2003] [notice] [client 128.104.16.134] hello:
[Thu Jun 5 14:57:13 2003] [notice] [client 128.104.16.134] cert no
good: Apache=SCALAR(0x8100308)->subprocess_env->{SSL_CLIENT_S_DN_C}
[Thu Jun 5 14:57:13 2003] [error] access to /var/www/html/test failed
for 128.104.16.134, reason: Client Cert not in correct form
[Thu Jun 5 14:57:13 2003] [crit] [client 128.104.16.134] configuration
error:
couldn't check user. No user file?: /test/
configuration data (in a statement):
SSLVerifyClient require
SSLVerifyDepth 10
SSLOptions +StrictRequire
SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128
# Force clients to use HTTPS
RewriteEngineon
RewriteCond %{HTTPS} !=on
RewriteRule .* - [F]
AuthName Test
AuthType Basic
PerlAuthenHandler Apache::AuthNx509
PerlSetVar CertComponent SSL_CLIENT_S_DN_C
PerlSetVar CertComponentValue US
PerlSetVar RemoteUserCertComponent SSL_CLIENT_S_DN_CN
require valid-user
Any ideas would be most appreciated. Thanks again!
--Ryan
Re: trouble with using $r->lookup_uri()
Aaron, It looks like this did the trickmy module doesn't quite work yet, but it isn't segfaulting anymore. Thanks! --Ryan On Fri, 2003-05-30 at 22:24, Aaron Ross wrote: > > 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 > >
trouble with using $r->lookup_uri()
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
