On Tue, Aug 02, 2005 at 03:03:45PM +0100, Joe Orton wrote:
> On Tue, Aug 02, 2005 at 03:23:44PM +0200, Martin Kraemer wrote:
> > The problem with the OID() "function" is that it where file() (or
> > another file() like function) return a single value, what OID()
> > stands for is an "array of zero or more values". But there is no
> > syntax to deal with arrays in place of expressions. I tried to
> > implement it as function first, but noticed that it would break when
> > an OID was specified more than once. In the ASF scenario, the
> > intention is to add multiple extensions with this OID, each one
> > containing as value a group name of which the client is member.
> > 
> > Because of the pre-existing syntax "<expr> in {value,value}", and
> > because "{value,value}" is effectively an array, I chose to implement
> > the OID() "function" as a special case of the "<expr> in" operator.
> 
> No, OK, that makes sense.  Perhaps a more general implementation would 
> be to have a "peerextlist()" which evalutes to a "wordlist" array like 
> the current function, along with a "peerext()" which evaluates to a 
> "word" (just the first extension with given name).

Hm. I'm not totally happy with this, or maybe I misunderstand
what you want to achieve.

I wanted something like

  SSLRequire "committers" in SSLPeerExtList("1.3.6.1.4.1.18060.1");

to mean "at least one extension with an OID of
1.3.6.1.4.1.18060.1 with a value of 'committers' exists in the
client cert".

How should SSLPeerExts() be used then? Maybe...

  SSLRequire SSLPeerExts("1.3.6.1.4.1.18060.1") =~ 
m/(^|,)(committers|administrators)(,|$)/

meaning: if in the ','-collapsed string (unclear; I am not happy
with the idea to just take the 1st occurrence) of all extension
values with an OID of 1.3.6.1.4.1.18060.1, does the word
"committers" or "administrator" start at the beginning or after a
comma, and does it end at the end or at another comma? (That
would be possible without further ado, because the left-hand-side
expression can also be an environment variable. And with the
','-collapsed string of all extension values available from
mod_setenvif, used like this:

  SetEnvIf SSLPeerExts("1.3.6.1.4.1.18060.1") "(.*)" SSL_PEER_EXT_ASF=$1
  SSLRequire %{ENV:SSL_PEER_EXT_ASF} =~ m/(^|,)(committers|administrators)(,|$)/

> I'd prefer peerexts() or peerextlist() given the above, to emphasize the 
> the fact that it returns a list, and to allow a peerext() which doesn't 
> do that, in the future.

I think that when similar functionality is offered, the naming
should be similar as well. If I use "SSLPeerExts" in
mod_setenvif, then of course it should be called SSLPeerExts or
SSLPeerExtList in mod_ssl too (both offer access to the SSL
certificate extension).

> Also note that apr_array_pstrcat(pool, array, ',') can be used instead 
> of all that code to flatten the array to a string.

Ah, yes, thanks.

> Other than the choice of name, this looks fine.  Please split out the 
> unrelated change to match tokens case-insensitively to a separate 
> commit.

Of course. BTW: do you think case insensitivity for the keywords
is a good idea? I do, but I don't know if it would cause
misinterpretation for some existing config files. Like, when
someone was looking for a string "EQ", will the parser now bail
out because it becomes a keyword?

  Martin
-- 
<[EMAIL PROTECTED]>         |     Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-48332 | 81730  Munich,  Germany

Reply via email to