Guys,
Thanks for all your suggestions, they are good suggestions but I'm not
going to reply to them individually.
The Valve for setting requested session Id works correctly. However I
implemented it POST only which is causing problems the application we are
using has a number of redirects.
Reverse proxy from a subdomain has been discussed internally and rejected,
this is to do with our business use case and the nature of the client who
we are dealing with. Its not pratical for us to mandate that they buy an
SSL cert for every top level domain that contains our application.
Get requests with a session Id in the url are out due to compliance reasons.
The same logic for A records in DNS which we considered also.
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.
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?
On Tue, Mar 31, 2015 at 2:58 PM, André Warnier <a...@ice-sa.com> wrote:
> Christopher Schultz wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> André,
>>
>> On 3/30/15 6:07 PM, André Warnier wrote:
>>
>>> Christopher Schultz wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>
>>>> Jeffrey,
>>>>
>>>> On 3/30/15 12:19 PM, Jeffrey Janner wrote:
>>>>
>>>>> -----Original Message----- From: Christopher Schultz [mailto:chris@
>>>>>> christopherschultz.net] Sent: Monday, March
>>>>>> 30, 2015 10:48 AM To: Tomcat Users List Subject: Re: Post
>>>>>> Session Id
>>>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>>>>
>>>>>> Wesley,
>>>>>>
>>>>>> On 3/30/15 3:57 AM, Wesley Acheson wrote:
>>>>>>
>>>>>>> On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz <
>>>>>>> ch...@christopherschultz.net> wrote:
>>>>>>>
>>>>>>> Wesley,
>>>>>>>
>>>>>>> On 3/29/15 1:15 PM, Wesley Acheson wrote:
>>>>>>>
>>>>>>>> A team I am working with use tomcat 7 as their web container. The
>>>>>>>>>> application cannot use url session tracking due to compliance
>>>>>>>>>> reasons.
>>>>>>>>>>
>>>>>>>>>> One of the requirements we are facing is that the
>>>>>>>>>> application should work in an iframe on the safari
>>>>>>>>>> web browser, which blocks all cookies.
>>>>>>>>>>
>>>>>>>>> Do you mean that Safari has been configured to block all cookies?
>>>>>>> Because Safari won't block cookies just because
>>>>>>> you are using an <iframe
>>>>>>>
>>>>>>>> .
>>>>>>>>>>
>>>>>>>>> Should have said its a third party domain name. That
>>>>>>>> can't change easily. Should have wrote Safari blocks all
>>>>>>>> third party cookies.
>>>>>>>>
>>>>>>> Okay, that explains it.
>>>>>>
>>>>>> Let me ask you... why is a path parameter (;jsessionid=f00)
>>>>>> unacceptable but not a request parameter? Or if it that you
>>>>>> want to have the parameters be in POST-parameters only?
>>>>>>
>>>>>> In terms of forgery and/or capturing session identifiers, there's
>>>>>> really no difference from a security perspective of
>>>>>> any of these strategies.
>>>>>>
>>>>>> - -chris
>>>>>>
>>>>> I may be being a little naïve here, but would the sessionCookieDomain
>>>>> parameter of the <Context> element work for
>>>>> the OP here?
>>>>>
>>>> No, because the "domain" of the "page" is considered to be
>>>> separate from the application being used, here (in an <iframe>).
>>>> Setting the domain of the cookie to the page-domain would
>>>> probably result in the cookie being (possibly) ignored by the
>>>> browser (because it came from the wrong domain) or the cookie
>>>> wouldn't be sent to the application because the domain wouldn't
>>>> match.
>>>>
>>>> That does bring-up another point, though: could the page-domain
>>>> be used to proxy requests through to the application? If so, none
>>>> of this work might need to be done. The browser would request
>>>> https://host.com/app and host.com would proxy through to
>>>> https://otherhost.com/app. It's more configuration and
>>>> networking work, but it's less application work which may be a
>>>> win.
>>>>
>>>> Re-reading this thread from the beginning, I still have a doubt as
>>> to whether I understand the issue correctly. That is because, as
>>> far as I know, an <iframe> within a Windows, is its own Window
>>> object, with its own "baseURI" etc.. And from the server's point of
>>> view, it is in fact like a separate "browser window", from which
>>> requests originate and to which responses are being sent, and it is
>>> for all intents and purposes indistinguishable from just another
>>> separate Window or Tab that would be opened on the same workstation
>>> by the same or another browser. So under what circumstances can a
>>> "session-id cookie" being sent by Tomcat to that "iframe Window" be
>>> considered as a third-party cookie and blocked by a browser ? (And
>>> if it were, would that not be a browser bug ?)
>>>
>>
>> http://www.mendoweb.be/blog/internet-explorer-safari-third-party-cookie-
>> problem/
>> http://stackoverflow.com/a/486569/276232
>>
>> Wesley, it looks like there are some hacks available that might solve
>> your problem.
>>
>> http://stackoverflow.com/a/4702110/276232
>> http://anantgarg.com/2010/02/18/cross-domain-cookies-in-safari/
>>
>> Unfortunately, it looks like these hacks are outdated and no longer
>> work: WebKit patched this "bug" so that iframe cookies are again ignored
>> ..
>>
>> It looks like there might be some other possibilities, but I can't
>> verify them ATM.
>>
>>
> So I would consider this as a browser bug. But nevertheless, that's how
> they work and one has to live with this for now. So back to the drawing
> board.
> The question here is : do the browsers reject the cookie
> a) just because it is addressed to an <iframe> ?
> or
> b) because (while being addressed to an <iframe>) the "domain" part of
> that cookie is determined to be different from the one from which the main
> window content is coming ?
>
> If (b), then the easiest solution would be to make it so that it isn't so.
>
> Let's imagine that the first main page is seen by the browser as coming
> from "http://serverA.domainA.com";, and that this contains an <iframe>
> loaded from "http://serverB.domainB.com";. With the response going to the
> iframe, comes a session-id cookie, whose domain portion is also "
> serverB.domainB.com", and this is (dubiously in my view) determined to be
> unacceptable by the browser, because it differs from "serverA.domainA.com".
> So the browser ignores the cookie.
>
> That issue would be solved, if the content of the <iframe> appeared to the
> browser as also come from "serverA.domainA.com" (like the main window's
> content), wouldn't it ?
>
> If so, why not make the server "serverA.domainA.com" act as a reverse
> proxy for the server serverB.domainB.com, and load the <iframe> from
> serverA too ?
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
