On 14 Mar 2015, at 1:04 AM, Konstantin Kolinko <knst.koli...@gmail.com> 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: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org