I presume this fixes #31418? Your patch makes sense to me. I could
argue that it could even be done *before* the SSLRequire checking, such
that the username is logged appropriately even if an SSLRequire
triggers a 403, but I doubt that matters much.
Thanks for looking at this!
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:
On Wed, Feb 02, 2005 at 10:07:56AM +, David Reid wrote:
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
+1
On Wed, 2 Feb 2005, Jim Jagielski wrote:
+1
Major +1 - though be aware of the fallout - internal redirects can play
nice heavoc.
DW.
Joe Orton wrote:
I presume this fixes #31418? Your patch makes sense to me. I could
argue that it could even be done *before* the SSLRequire checking, such
that the username is logged appropriately even if an SSLRequire
triggers a 403, but I doubt that matters much.
fwiw that's the route
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
My only concern ... does this new scope pair up properly if the
user cert has been renegotiated? If so +1
Bill
At 07:17 PM 2/1/2005, you wrote:
Index: ssl_engine_kernel.c
===
--- ssl_engine_kernel.c (revision 123890)
+++
