[mod_python] req.user and SSL?

>>I have a problem reading req.user when using mod-SSL with the
>>+FakeBasicAuth option and setting SSLUser:  req.user always seems
>>to be undefined.
...
> I understood that the mod-ssl directive
> >SSLUserName SSL_CLIENT_S_DN_X509
> tells it to set the subject DN as req.user.  Did I understand this
> incorrectly?

>From the mod_ssl docs:

    "Note that this [SSLUserName] directive has no effect
    if the FakeBasic option is used."

The FaseBasicAuth processing is done early in the UserCheck phase. 
Essentially what it does is to synthesize an "Authorization" header as
if the user agent sent it; but otherwise doesn't set anything else. 
In this case the username will be the client DN string, and the
password will be "password", and the authorization scheme is "Basic". 
Thus it is still up to a later handler, such as auth_basic, to then
re-interpret the authorization header, and set up the req->user field.
 Of course this means that the DN and "password" needs to be in one of
it's backend provider databases (httpasswd, LDAP, etc), or it will be
rejected as a bad login.

[To prevent spoofing, any actual Authorization header sent by the real
user agent is rejected if the password is "password" and the username
starts with a "/".  So likewise if that username starts with "/" and
the password was "password", you know it was a synthesized "fake"
login by mod_ssl.]

The SSLUserName processing on the other hand is done in the middle of
the Access phase.  The req->user is set directly to whatever ssl
variable you specify (which internally uses the ssl_var_lookup()
method).  Note though that this phase is designed for access control,
not for authentication.  So if it gets this far, the client cert has
already been "trusted" as a valid user.  There obviously is no
password and auth_basic doesn't get involved.

Note that mod_ssl is full of informational logging, so you may be able
to see what's going on by capturing the INFO level log output from
apache.


> This DN is a string; would there be any requirements for
> accepting a string as user name (e.g., illegal chars)?

The only restriction I know of is that the user name can not contain a
colon ":" (this restriction comes from the HTTP basic and digest RFC
2617), nor a zero-byte.  Note that the DN will always start with a "/"
character.


> >Second is that mod_ssl only populates req.user from a MIDDLE hook of the
> >access handler.
>
> Ok, so possibly I don't see it in the access hander, but then I should see
> it in the Fixup stage, shouldn't I?

Should be correct.  Of course you can still get the DN yourself via
ssl_var_lookup() and just ignore the req->user.


> Would you recommend to take the trunk instead?

As Graham said the trunk is probably okay.  But if you're just a bit
more cautious, you can grab a stable release (3.2.7 for instance) and
just apply the one set of patches in MODPYTHON-94.

If you do that though just one head's up.... the patch attached to the
issue uses the method name "ssl_var()", whereas it is integrated on
the trunk (and in future relases) as "ssl_var_lookup()".  There's a
couple other tiny differences too...so read all the notes to the #94
issue and decide for yourself whether you go with the whole trunk or
just this patch.

Also, any feedback (good or bad) is certainly welcome, as this SSL
functionality gets much narowwer testing than other parts of
mod_python.
--
Deron Meranda