Am 31.03.2015 um 15:19 schrieb Wesley Acheson:
Currently I'm trying to use <tracking-mode>SSL</tracking-mode> in web.xml
but just running some local tests it appears that there are a number of
problems when using the JK connector and using this mechanism.
First issue: Even though the requests are going through AJP which supports
the SSL context information propegation, It appears I need to add a second
connector to serve over https. This is because the logic in
ApplicationConnector.java
for (Connector connector : connectors) {
if (Boolean.TRUE.equals(connector.getAttribute("SSLEnabled"))) {
supportedSessionTrackingModes.add(SessionTrackingMode.SSL);
break;
}
}
Looks like the AJP connector doesn't accept that attribute.
Something we could fix, but you found a workaround.
Second issue: This is the actual issue that blocks us.
When going over mod_jk to a tomcat instance it appears that the request
attribute SSL_SESSION_ID isn't populated on the first few requests to the
server. However it is populated on subsequent requests.
This is causing the following exception.
java.lang.NullPointerException
at
org.apache.catalina.connector.CoyoteAdapter.parseSessionSslId(CoyoteAdapter.java:985)
at
org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:765)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:416)
at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
Closing and repopening the browser causes the same issue to occur again.
Which means that I'm going to have to go back to posting the id, after
places where we don't control redirects back to our domain, I'm going to
have to issue a one time session lookup token to lookup the session Id.
This means sharing a data source with the Valve and the web applications.
(basically a string->string hashmap) Hopefully I can use JNDI or similar
for a local map if not its going to be needed to be backed by a database.
So remaining questions are two: How to get the SSL_SESSION_ID populated on
initial requests? Can I share some object in memory with tomcat as the
container(in a valve) and the web application?
I currently see no reason, why it shouldn't be populated right from the
start. Could you please check
- whether Apache always provides SSL_SESSION_ID:
Set "SSLOptions +StdEnvVars" and add %{SSL_SESSION_ID}X to your access
log (using CustomLog and a LogFormat).
This will log the ssl session id with every request that is handled by
Apache in the Apache access log. If the field does not contain an id,
then mod_jk has no chance of forwarding it and we need to solve that part.
- whether Tomcat sees the right IDs:
You can add %{javax.servlet.request.ssl_session}r to the pattern of the
AccessLogValve to add the ssl session id to your Tomcat access log.
If you can see the ID for the problematic cases in the httpd access log
but not in the Tomcat one, I'll do a little test here to reproduce.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
