Re: [PATCH] set username from certificates at a more appropriate time

[David Reid]

William A. Rowe, Jr. wrote:
My only concern ... does this new scope pair up properly if the
user cert has been renegotiated?  If so +1
I'm unable to test that here, but maybe if someone has a system where 
renegotiation is testable...

david
Bill
At 07:17 PM 2/1/2005, you wrote:
Index: ssl_engine_kernel.c
===================================================================
--- ssl_engine_kernel.c (revision 123890)
+++ ssl_engine_kernel.c (working copy)
@@ -798,6 +798,20 @@
       }
   }
+    /* If we're trying to have the user name set from a client
+     * certificate then we need to set it here. This should be safe as
+     * the user name probably isn't important from an auth checking point
+     * of view as the certificate supplied acts in that capacity.
+     * However, if FakeAuth is being used then this isn't the case so
+     * we need to postpone setting the username until later.
+     */
+    if ((dc->nOptions & SSL_OPT_FAKEBASICAUTH) == 0 && dc->szUserName) {
+        char *val = ssl_var_lookup(r->pool, r->server, r->connection,
+                                   r, (char *)dc->szUserName);
+        if (val && val[0])
+            r->user = val;
+    }
+
   /*
    * Else access is granted from our point of view (except vendor
    * handlers override). But we have to return DECLINED here instead
@@ -1042,17 +1056,6 @@
   }
   /*
-     * Set r->user if requested
-     */
-    if (dc->szUserName) {
-        val = ssl_var_lookup(r->pool, r->server, r->connection,
-                             r, (char *)dc->szUserName);
-        if (val && val[0]) {
-            r->user = val;
-        }
-    }
-
-    /*
    * Annotate the SSI/CGI environment with standard SSL information
    */
   /* the always present HTTPS (=HTTP over SSL) flag! */