httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kraemer <mar...@apache.org>
Subject [PATCH] mod_setenvif.c [was: ssl_ext_lookup #2]
Date Thu, 22 Sep 2005 11:04:25 GMT
On Tue, Sep 20, 2005 at 05:33:30PM +0100, Joe Orton wrote:
> >   SetEnvIf SSL_PeerExtList("1.3.6.1.4.1.18060.1") \
> >           "(committers|administrators)" \
> >           ThisUserHasAValidCert=$1
> > 
> > Later on, you can control access (in dir context, if desired) by
> > 
> >   allow from env=ThisUserHasAValidCert
> 
> That's just SSLRequire reimplemented badly, as you say.  What's the real 
> use-case for this feature, what problem are you trying to solve?

If used for "allow from env=", you are right. But environment variables
do have a much more global usage scenario.

I see a usage scenario in anything from CGIs (and .shtml / .php / .pl)
to custom error documents, or rewriting and filtering. The patch
just extends the already existing availability of standard predefined
variables which allow access to the cert's main data to also get
access to any other string data contained in the cert's extensions
(without having to modify each and every Apache module that needs
access to those strings).

For the single case of an internal SSL renegotiation in mod_ssl during
response processing, there should of course...
a) be a CAVEAT section in the docs for mod_ssl and/or mod_setenvif
   that describe the problem
b) be a discussion about the side effects of such a renegotiation
   on the already-sampled request status (what aspect of the already
   collected infomation has been invaidated by the renegotiation, and
   how can it be updated?)

I attached a patch to the xml docs, and an updated version of the patch
you provided, modified for a stricter syntax check.

  Martin
-- 
<Martin.Kraemer@Fujitsu-Siemens.com>         |     Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-48332 | 81730  Munich,  Germany

Mime
View raw message