On 14 Mar 2015, at 1:04 AM, Konstantin Kolinko <[email protected]> wrote:
> You are using JRE's default java.util.logging.LogManager.
>
> You need to configure JRE to use the Tomcat JULI implementation of log
> manager with
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
>
> The JRE class is usable, but its logging.properties format is a bit different.
Adding the above to Eclipse’s launcher configuration brought sanity back to the
logging.
What this revealed was that no realm decisions were being made - we weren’t
getting that far.
Placing a watchpoint on the “status” variable in the response revealed the
point at which we were getting the 403.
In my case switching from basic auth to cert meant changing the tomcat protocol
from HTTP to AJP, and this in turn caused a
org.apache.catalina.valves.RemoteAddrValve configuration to kick in, which now
no longer pointed at localhost (address of Apache proxy) but rather the browser
IP, thanks to AJP:
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127.0.0.1”/>
Stepping through the org.apache.catalina.valves.RemoteAddrValve implementation
in the debugger showed that when it returned the 403, it logged nothing in the
log, and it returned no explanatory message in the response. Ideally this needs
to be fixed: https://bz.apache.org/bugzilla/show_bug.cgi?id=57705
Now I get the basic authentication to hit as normal.
Changing the auth-type to CLIENT-CERT shows that the username has been replaced
by the subject-DN of the cert, which is progress.
Regards,
Graham
—
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
