Re: Post Session Id
On Wed, Apr 1, 2015 at 11:50 AM, Rainer Jung rainer.j...@kippdata.de
wrote:
Am 31.03.2015 um 15:19 schrieb Wesley Acheson:
Currently I'm trying to use tracking-modeSSL/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.
Yeah I'm not sure if that is still an issue in TC8. When I'm not trying to
get something working in deadlines I'll try to provide a bug report maybe a
patch but I'm not sure if its the validation logic thats wrong or if the
connector should instead should have that property.
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).
What I did before is I added the ssl options to apache and did an ngrep on
port 8009 loopback interface, apache was not sending it over the wire. It
was sending other SSL parameters
Now this could be just some error in my configuration I don't have it here
to check. I used whatever apache was installed by default by apt-get in
mint. And I couldn't find a precompiled mod_jk.so so I ended up compiling
it.
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.
I'm not at the computer where I saw this behaviour and as above I'm not
sure if its my fault. When I am back at the computer unfortunately I've
other things to solve. (such as my hacked together session tracking).
It looks like I'm way off the beaten path with trying SSL session over
mod_jk so I'm not sure if a fix is all that usefull to anyone?
- 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
Re: Post Session Id
Because if they are reverse proxying on a subdomain then the subdomain needs a ssl cert basically. On Tue, Mar 31, 2015 at 5:35 PM, André Warnier a...@ice-sa.com wrote: Wesley Acheson wrote: This is getting off topic. The website that surrounds our website is available under multiple domains. I.e. They white label their product. Hi. If you do not want to pursue this, I cannot and do not want to force you. But on the base of the scarce info available : if they are the surrounding site, and your application lives in the iframe, then all they have to do is set up *their* server as the proxy to you, not so ? And in that case, why would they need to get any more certs than they already have ? On Tue, Mar 31, 2015 at 4:52 PM, André Warnier a...@ice-sa.com wrote: Wesley Acheson wrote: Andre that works perfectly fine but not for our use case. Ok, thanks for the confirmation. My logical world is back on track now. Not to nitpick, but your previous post was the first one in which you mentioned SSL as part of the equation, wasn't it ? If you still have a moment : in that previous post, you wrote Its not pratical for us to mandate that they buy an SSL cert for every top level domain that contains our application. Could you in a few words explain why that would be necessary ? I guess that I still do not clearly see that use case. Maybe just having a look at the initial page which you mention, could help ? 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
Re: Post Session Id
for us to mandate that they buy an SSL cert for every top level domain that contains our application. Could you in a few words explain why that would be necessary ? I guess that I still do not clearly see that use case. Maybe just having a look at the initial page which you mention, could help ? 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
Re: Post Session Id
Am 31.03.2015 um 15:19 schrieb Wesley Acheson:
Currently I'm trying to use tracking-modeSSL/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
Re: Post Session Id
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:ch...@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
Re: Post Session Id
-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:ch...@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. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVGo1RAAoJEBzwKT+lPKRYRMsQAL2/czwcAmb4rQh7iz4euvDJ eI0Q+PpVX4qmn/d5C7DHH69OckELdQNooYlpZ/QmwTerSPary6BML/T6WHPy35L8 ZJsDEEO2d8Renem8AYbpRoGwH9KpHSrVa+Fx40sN+u0mh+28IbV7Iq8sPgIn6VlC WFV/c+98l2l7FiM7AGes+JpN4NnRxcoHQQKBMX0Rv8Og5fjNGz+CLD0mQhiPo1yo DJNhto7Xe2v9hmaJYsV30XPGEyi+SCrwbSQy+IcsLXFNKB9ZFHt3AiX5Ck3O2wz9 +x8dQXmHJLZPuU+Ew5jvrF3be0rXbwlaC1JO9StdxXUyk5abcJEPGaV4lUUNxPAs dyo1j+5fm+TH0NcdD96EEMzLaN2+n3S5H4GsrXUESeyL95wLHUj1fvDxWUmoTx/9 xoN8VI+sj8NowjpskuIyTPuhZfdeScOjJq4WrzfpvpYQy8RoXjf223IM1TjH2Y7O fC68nj4ogRQyPLuBxvPQRRp11JE9QK7iBMJ4zdqrd0z+DelnAxH0cEvJhwMzriwZ QMpZKJeDq6WkScoVW2M8yeh+6cl0YqntIwGiJT49bdpLYpPQr51sVGC7R/Spk5Sl doP9CJCHzfEmluhVNrvhVmPyI5AtUrq5J629Oz7A8TcqJaq15WB0xfQcuj/ASfBt OtsaEQK2ycPRHLFqgbej =po7U -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Post Session Id
Andre that works perfectly fine but not for our use case. 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
Re: Post Session Id
Wesley Acheson wrote: Andre that works perfectly fine but not for our use case. Ok, thanks for the confirmation. My logical world is back on track now. Not to nitpick, but your previous post was the first one in which you mentioned SSL as part of the equation, wasn't it ? If you still have a moment : in that previous post, you wrote Its not pratical for us to mandate that they buy an SSL cert for every top level domain that contains our application. Could you in a few words explain why that would be necessary ? I guess that I still do not clearly see that use case. Maybe just having a look at the initial page which you mention, could help ? 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
Re: Post Session Id
Wesley Acheson wrote: This is getting off topic. The website that surrounds our website is available under multiple domains. I.e. They white label their product. Hi. If you do not want to pursue this, I cannot and do not want to force you. But on the base of the scarce info available : if they are the surrounding site, and your application lives in the iframe, then all they have to do is set up *their* server as the proxy to you, not so ? And in that case, why would they need to get any more certs than they already have ? On Tue, Mar 31, 2015 at 4:52 PM, André Warnier a...@ice-sa.com wrote: Wesley Acheson wrote: Andre that works perfectly fine but not for our use case. Ok, thanks for the confirmation. My logical world is back on track now. Not to nitpick, but your previous post was the first one in which you mentioned SSL as part of the equation, wasn't it ? If you still have a moment : in that previous post, you wrote Its not pratical for us to mandate that they buy an SSL cert for every top level domain that contains our application. Could you in a few words explain why that would be necessary ? I guess that I still do not clearly see that use case. Maybe just having a look at the initial page which you mention, could help ? 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
Re: Post Session Id
This is getting off topic. The website that surrounds our website is available under multiple domains. I.e. They white label their product. On Tue, Mar 31, 2015 at 4:52 PM, André Warnier a...@ice-sa.com wrote: Wesley Acheson wrote: Andre that works perfectly fine but not for our use case. Ok, thanks for the confirmation. My logical world is back on track now. Not to nitpick, but your previous post was the first one in which you mentioned SSL as part of the equation, wasn't it ? If you still have a moment : in that previous post, you wrote Its not pratical for us to mandate that they buy an SSL cert for every top level domain that contains our application. Could you in a few words explain why that would be necessary ? I guess that I still do not clearly see that use case. Maybe just having a look at the initial page which you mention, could help ? 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
Re: Post Session Id
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-modeSSL/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
Re: Post Session Id
On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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. For this purpose I'd like to post some value around that acts as a session Id. However I'm not sure if this is possible? If you write a Valve (which would be Tomcat-specific, and not work under other servlet containers), you could change the way Tomcat reads session identifiers from the request (and use a request parameter instead of a path parameter). I understand that the solution at the moment would be container specific. Or you could handle session-management yourself and not use servlet-spec-style session-tracking (which would be WAY more invasive to your application). In the longer term this is probably better. For the immediate term I just need the lease invasive approach for the application. *I'm aware that this won't work for common paradigms such as POST-REDIRECT-GET.* Looking at CoyoteAdaptor.java seems to suggest that session Id can only be retrieved using SSL COOKIE and URL. COOKIE is out because of third party issues. URL is out because of compliance. SSL may be a possiblity but only if it doesn't involve custom client certificates. Is there any good place to hook in a post parameter for retrieving and reattaching the session? I've not done this before. CoyoteAdapter calls request.setRequestedSessionId in a few places, and I don't believe CoyoteAdapter can be overridden or replaced directly. If you had a Valve that ran before anything else, you might be able to capture the request, read a request parameter, and then call setRequestedSessionId yourself with that replacement value. Thanks very much I'm going to read up on valves now. YMMV - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVGJYFAAoJEBzwKT+lPKRYn8oP/0LIWZKl5Nf/bYdN1BeosGFF 6hLS/mEDZ+XUD/NMpGpTHjoin3+32m7kGKEGCCApQDc4GAUlIwJGzLeLPsGfFaoo QXXyM6XUfpHWmJaEPtAySe0CZ/fwOKvL/DKuuO7UbtjFmNc8Pm/e87p5lmprsaQ1 C+4pfXsV5ltdDO8eZU0ofOHAXA0qkDuizeixwEcG3sXnNqF4Hr7Oq4gF0TKwCAU9 6Hce0NYVY61YY64U0m+dCCsH5a9hMUlu48YGDA9JemKmeNLexR3TrxFC8LT8iqUW jXNygDD7GBfFBhIiYujUo3HwSCNW091OMy6Vb0DhcSOlL11LVpK2+eNLZ1aM3kHI 881Onen2evMjzZ3PcALw2SqN3Cmr8dqMp0YhrJc2jsZ6OXBrYSuSCYCw4A0tDlN7 GTusoqFobmipgXu+sksZh5A6h5uyThVTLikG3CQ72wvTDMzRBh1YrNPc027BLuKN k/KOoBv3Lkyan+pSEbzQCCchB2IQ/CSFHoD8jgfzcHehJ5qB1Mrwo97kwsh1qbvk IjGssbqyDrTmfrKVyl1ypeCi18l7pn9GrTzJwFoNUxmfd+42elwCrRPUdCYYZuR8 9Ne8uYegBwnvRQpDN5RCK73Bqpyi2lgyP10Ph20TvnQ3ACDNbb6247TOTPGnItGr G5g/FyojfAtvlnhe7+r4 =0axs -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Post Session Id
On Mon, Mar 30, 2015 at 10:24 AM, Aurélien Terrestris aterrest...@gmail.com wrote: If you write a Valve (which would be Tomcat-specific, and not work under other servlet containers), you could change the way Tomcat reads session identifiers from the request (and use a request parameter instead of a path parameter). Maybe could you also have a look on Filters since they're made for modifying the request before it reaches the servlet (or modifying the response after it leaves the servlet) : http://www.oracle.com/technetwork/java/filters-137243.html Yes I know how filters work. However their within the lifecycle of the webapp. A filter can't associate a session with a request :( 2015-03-30 9:57 GMT+02:00 Wesley Acheson wesley.ache...@gmail.com: On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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. For this purpose I'd like to post some value around that acts as a session Id. However I'm not sure if this is possible? If you write a Valve (which would be Tomcat-specific, and not work under other servlet containers), you could change the way Tomcat reads session identifiers from the request (and use a request parameter instead of a path parameter). I understand that the solution at the moment would be container specific. Or you could handle session-management yourself and not use servlet-spec-style session-tracking (which would be WAY more invasive to your application). In the longer term this is probably better. For the immediate term I just need the lease invasive approach for the application. *I'm aware that this won't work for common paradigms such as POST-REDIRECT-GET.* Looking at CoyoteAdaptor.java seems to suggest that session Id can only be retrieved using SSL COOKIE and URL. COOKIE is out because of third party issues. URL is out because of compliance. SSL may be a possiblity but only if it doesn't involve custom client certificates. Is there any good place to hook in a post parameter for retrieving and reattaching the session? I've not done this before. CoyoteAdapter calls request.setRequestedSessionId in a few places, and I don't believe CoyoteAdapter can be overridden or replaced directly. If you had a Valve that ran before anything else, you might be able to capture the request, read a request parameter, and then call setRequestedSessionId yourself with that replacement value. Thanks very much I'm going to read up on valves now. YMMV - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVGJYFAAoJEBzwKT+lPKRYn8oP/0LIWZKl5Nf/bYdN1BeosGFF 6hLS/mEDZ+XUD/NMpGpTHjoin3+32m7kGKEGCCApQDc4GAUlIwJGzLeLPsGfFaoo QXXyM6XUfpHWmJaEPtAySe0CZ/fwOKvL/DKuuO7UbtjFmNc8Pm/e87p5lmprsaQ1 C+4pfXsV5ltdDO8eZU0ofOHAXA0qkDuizeixwEcG3sXnNqF4Hr7Oq4gF0TKwCAU9 6Hce0NYVY61YY64U0m+dCCsH5a9hMUlu48YGDA9JemKmeNLexR3TrxFC8LT8iqUW jXNygDD7GBfFBhIiYujUo3HwSCNW091OMy6Vb0DhcSOlL11LVpK2+eNLZ1aM3kHI 881Onen2evMjzZ3PcALw2SqN3Cmr8dqMp0YhrJc2jsZ6OXBrYSuSCYCw4A0tDlN7 GTusoqFobmipgXu+sksZh5A6h5uyThVTLikG3CQ72wvTDMzRBh1YrNPc027BLuKN k/KOoBv3Lkyan+pSEbzQCCchB2IQ/CSFHoD8jgfzcHehJ5qB1Mrwo97kwsh1qbvk IjGssbqyDrTmfrKVyl1ypeCi18l7pn9GrTzJwFoNUxmfd+42elwCrRPUdCYYZuR8 9Ne8uYegBwnvRQpDN5RCK73Bqpyi2lgyP10Ph20TvnQ3ACDNbb6247TOTPGnItGr G5g/FyojfAtvlnhe7+r4 =0axs -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Post Session Id
If you write a Valve (which would be Tomcat-specific, and not work under other servlet containers), you could change the way Tomcat reads session identifiers from the request (and use a request parameter instead of a path parameter). Maybe could you also have a look on Filters since they're made for modifying the request before it reaches the servlet (or modifying the response after it leaves the servlet) : http://www.oracle.com/technetwork/java/filters-137243.html 2015-03-30 9:57 GMT+02:00 Wesley Acheson wesley.ache...@gmail.com: On Mon, Mar 30, 2015 at 2:17 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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. For this purpose I'd like to post some value around that acts as a session Id. However I'm not sure if this is possible? If you write a Valve (which would be Tomcat-specific, and not work under other servlet containers), you could change the way Tomcat reads session identifiers from the request (and use a request parameter instead of a path parameter). I understand that the solution at the moment would be container specific. Or you could handle session-management yourself and not use servlet-spec-style session-tracking (which would be WAY more invasive to your application). In the longer term this is probably better. For the immediate term I just need the lease invasive approach for the application. *I'm aware that this won't work for common paradigms such as POST-REDIRECT-GET.* Looking at CoyoteAdaptor.java seems to suggest that session Id can only be retrieved using SSL COOKIE and URL. COOKIE is out because of third party issues. URL is out because of compliance. SSL may be a possiblity but only if it doesn't involve custom client certificates. Is there any good place to hook in a post parameter for retrieving and reattaching the session? I've not done this before. CoyoteAdapter calls request.setRequestedSessionId in a few places, and I don't believe CoyoteAdapter can be overridden or replaced directly. If you had a Valve that ran before anything else, you might be able to capture the request, read a request parameter, and then call setRequestedSessionId yourself with that replacement value. Thanks very much I'm going to read up on valves now. YMMV - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVGJYFAAoJEBzwKT+lPKRYn8oP/0LIWZKl5Nf/bYdN1BeosGFF 6hLS/mEDZ+XUD/NMpGpTHjoin3+32m7kGKEGCCApQDc4GAUlIwJGzLeLPsGfFaoo QXXyM6XUfpHWmJaEPtAySe0CZ/fwOKvL/DKuuO7UbtjFmNc8Pm/e87p5lmprsaQ1 C+4pfXsV5ltdDO8eZU0ofOHAXA0qkDuizeixwEcG3sXnNqF4Hr7Oq4gF0TKwCAU9 6Hce0NYVY61YY64U0m+dCCsH5a9hMUlu48YGDA9JemKmeNLexR3TrxFC8LT8iqUW jXNygDD7GBfFBhIiYujUo3HwSCNW091OMy6Vb0DhcSOlL11LVpK2+eNLZ1aM3kHI 881Onen2evMjzZ3PcALw2SqN3Cmr8dqMp0YhrJc2jsZ6OXBrYSuSCYCw4A0tDlN7 GTusoqFobmipgXu+sksZh5A6h5uyThVTLikG3CQ72wvTDMzRBh1YrNPc027BLuKN k/KOoBv3Lkyan+pSEbzQCCchB2IQ/CSFHoD8jgfzcHehJ5qB1Mrwo97kwsh1qbvk IjGssbqyDrTmfrKVyl1ypeCi18l7pn9GrTzJwFoNUxmfd+42elwCrRPUdCYYZuR8 9Ne8uYegBwnvRQpDN5RCK73Bqpyi2lgyP10Ph20TvnQ3ACDNbb6247TOTPGnItGr G5g/FyojfAtvlnhe7+r4 =0axs -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Post Session Id
Thanks Christopher, I believe this was working by the time of Tomcat 4.. but not completely sure, it was a long time ago :) 2015-03-30 16:14 GMT+02:00 Christopher Schultz ch...@christopherschultz.net: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aurélien, On 3/30/15 4:24 AM, Aurélien Terrestris wrote: If you write a Valve (which would be Tomcat-specific, and not work under other servlet containers), you could change the way Tomcat reads session identifiers from the request (and use a request parameter instead of a path parameter). Maybe could you also have a look on Filters since they're made for modifying the request before it reaches the servlet (or modifying the response after it leaves the servlet) : http://www.oracle.com/technetwork/java/filters-137243.html This won't work well with Tomcat's authorization checks, since they occur before the filter chain in invoked. - -chris 2015-03-30 9:57 GMT+02:00 Wesley Acheson wesley.ache...@gmail.com: 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. For this purpose I'd like to post some value around that acts as a session Id. However I'm not sure if this is possible? If you write a Valve (which would be Tomcat-specific, and not work under other servlet containers), you could change the way Tomcat reads session identifiers from the request (and use a request parameter instead of a path parameter). I understand that the solution at the moment would be container specific. Or you could handle session-management yourself and not use servlet-spec-style session-tracking (which would be WAY more invasive to your application). In the longer term this is probably better. For the immediate term I just need the lease invasive approach for the application. *I'm aware that this won't work for common paradigms such as POST-REDIRECT-GET.* Looking at CoyoteAdaptor.java seems to suggest that session Id can only be retrieved using SSL COOKIE and URL. COOKIE is out because of third party issues. URL is out because of compliance. SSL may be a possiblity but only if it doesn't involve custom client certificates. Is there any good place to hook in a post parameter for retrieving and reattaching the session? I've not done this before. CoyoteAdapter calls request.setRequestedSessionId in a few places, and I don't believe CoyoteAdapter can be overridden or replaced directly. If you had a Valve that ran before anything else, you might be able to capture the request, read a request parameter, and then call setRequestedSessionId yourself with that replacement value. Thanks very much I'm going to read up on valves now. YMMV -chris - - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVGVpSAAoJEBzwKT+lPKRY1jkP/0Onuep4c7wOO1UeLB8zeuFc ZOWf7YXhGpzxufTLJAsBrxtZpM/2EOu1Ht1MXjEFaQiSCqnpUsK9m9SnCg98uajw terP6eKGiOO5cIg4+oR6mAdxsDYWNNg+Ksdk1ZUauKKxX3UmKWDNhCLazVUtqSJW qIocqskAYH3VIqhxLbtEyQIGnyy7KQFRFwSS/gQj2aUsklX85+6UNuVZzbGgo6MK q3VcEhOyUYuuvQB78+DP+D1iiYNP1NAyqRtjkBZYilb34LegQvU0jIunvKUzvFqJ w6GLeXqVscVV9wdD9RYf/iIt9K63k+f2xZ+82gNN9IcknNW5o0hMFa+tdHSnjzEk X4kSmrw/e5RBX1yXeD16kadrZfwXsgIXFj9b4ELPaT/Z28ED0vb7GEh3QGC0Q36J X5hAPlZo+G5iXJb7xk8G0QTle3lgWuzeUMYqbIZepUkpvpkjVPqk5w+SkuqLWfzt IoWfL1aIAv8EgA5vS+sQ6ADsT1yYRLzm/n3R2sGnE5Rk8uNDV8C5cqfC7489mUnh SFJrKhnmcW2Jc84Vq+I3ZjAkneN3uBS6lOrX/VuuV3BT4zTOS3Ak/v7yJZ4r22RN qCvceHciuAnNKkUb33jZYwY2eZBfzb3myyjx6guHXQgXZZbzVX7PESDenujrT2FO BoEwFR4BfjOxSrzyoa43 =G7fj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail:
Re: Post Session Id
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aurélien, On 3/30/15 4:24 AM, Aurélien Terrestris wrote: If you write a Valve (which would be Tomcat-specific, and not work under other servlet containers), you could change the way Tomcat reads session identifiers from the request (and use a request parameter instead of a path parameter). Maybe could you also have a look on Filters since they're made for modifying the request before it reaches the servlet (or modifying the response after it leaves the servlet) : http://www.oracle.com/technetwork/java/filters-137243.html This won't work well with Tomcat's authorization checks, since they occur before the filter chain in invoked. - -chris 2015-03-30 9:57 GMT+02:00 Wesley Acheson wesley.ache...@gmail.com: 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. For this purpose I'd like to post some value around that acts as a session Id. However I'm not sure if this is possible? If you write a Valve (which would be Tomcat-specific, and not work under other servlet containers), you could change the way Tomcat reads session identifiers from the request (and use a request parameter instead of a path parameter). I understand that the solution at the moment would be container specific. Or you could handle session-management yourself and not use servlet-spec-style session-tracking (which would be WAY more invasive to your application). In the longer term this is probably better. For the immediate term I just need the lease invasive approach for the application. *I'm aware that this won't work for common paradigms such as POST-REDIRECT-GET.* Looking at CoyoteAdaptor.java seems to suggest that session Id can only be retrieved using SSL COOKIE and URL. COOKIE is out because of third party issues. URL is out because of compliance. SSL may be a possiblity but only if it doesn't involve custom client certificates. Is there any good place to hook in a post parameter for retrieving and reattaching the session? I've not done this before. CoyoteAdapter calls request.setRequestedSessionId in a few places, and I don't believe CoyoteAdapter can be overridden or replaced directly. If you had a Valve that ran before anything else, you might be able to capture the request, read a request parameter, and then call setRequestedSessionId yourself with that replacement value. Thanks very much I'm going to read up on valves now. YMMV -chris - - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVGVpSAAoJEBzwKT+lPKRY1jkP/0Onuep4c7wOO1UeLB8zeuFc ZOWf7YXhGpzxufTLJAsBrxtZpM/2EOu1Ht1MXjEFaQiSCqnpUsK9m9SnCg98uajw terP6eKGiOO5cIg4+oR6mAdxsDYWNNg+Ksdk1ZUauKKxX3UmKWDNhCLazVUtqSJW qIocqskAYH3VIqhxLbtEyQIGnyy7KQFRFwSS/gQj2aUsklX85+6UNuVZzbGgo6MK q3VcEhOyUYuuvQB78+DP+D1iiYNP1NAyqRtjkBZYilb34LegQvU0jIunvKUzvFqJ w6GLeXqVscVV9wdD9RYf/iIt9K63k+f2xZ+82gNN9IcknNW5o0hMFa+tdHSnjzEk X4kSmrw/e5RBX1yXeD16kadrZfwXsgIXFj9b4ELPaT/Z28ED0vb7GEh3QGC0Q36J X5hAPlZo+G5iXJb7xk8G0QTle3lgWuzeUMYqbIZepUkpvpkjVPqk5w+SkuqLWfzt IoWfL1aIAv8EgA5vS+sQ6ADsT1yYRLzm/n3R2sGnE5Rk8uNDV8C5cqfC7489mUnh SFJrKhnmcW2Jc84Vq+I3ZjAkneN3uBS6lOrX/VuuV3BT4zTOS3Ak/v7yJZ4r22RN qCvceHciuAnNKkUb33jZYwY2eZBfzb3myyjx6guHXQgXZZbzVX7PESDenujrT2FO BoEwFR4BfjOxSrzyoa43 =G7fj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Post Session Id
Wesley Acheson wrote: On Mon, Mar 30, 2015 at 10:24 AM, Aurélien Terrestris aterrest...@gmail.com wrote: If you write a Valve (which would be Tomcat-specific, and not work under other servlet containers), you could change the way Tomcat reads session identifiers from the request (and use a request parameter instead of a path parameter). Maybe could you also have a look on Filters since they're made for modifying the request before it reaches the servlet (or modifying the response after it leaves the servlet) : http://www.oracle.com/technetwork/java/filters-137243.html Yes I know how filters work. However their within the lifecycle of the webapp. A filter can't associate a session with a request :( A bit of thinking out of the box, maybe futile but one never knows. The basic reason why it doesn't work now, is because these cookies are somehow third-party cookies. Of course I don't know your application, but isn't there some way in which this can be changed, to make these into first-party cookies ? There maybe you could use a servlet filter to catch/set the cookie headers, and if needed proxy something to the third-party server involved ? To elaborate : if the main application is sending third-party cookies to the browser, then these are Set-Cookie headers in the responses, said cookies having a domain part that is not the server of the application. A servlet filter could rewrite these cookie headers, and change the domain part to be the main server. Then they would be accepted by the browser. Similarly, since the cookies would then be re-sent to the main server by the browser as Cookie headers, they could be caught by the same servlet filter in the requests, and whatever needs to happen with them, done then. (Having the servlet filter recognise such requests, and possibly proxying them to the third-party server). Complicated, but maybe less so (and less intrusive) than changing the whole application logic. Further along the same line of thought, one could put a front-end Apache httpd server in front of Tomcat, and do all this kind of stuff there, where there are already numerous standard tools to do such things as URL rewriting, Cookie rewriting, conditional proxying etc., in a generally simpler way than under a Java servlet engine like Tomcat. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVGXArAAoJEBzwKT+lPKRYzcgQAJc4Kean12GHpSv63+I8TaVT cNV7r7Rq+HYMpRIJG8qVFd95ic0/OVPkm5dueO7QpIA/EBVPSnWi/fItcZt9tXJq m90salW0ey5jF8L8C9CTJ0z1j4PnSy9jlCIS/oU/9F2UrPGGUkeWdYy5lQWM+VDr rPcjxvim7QBWg6+toATt9gnKeH3zHFoLkHF0DdMSlbO2Ro0GTO/Mm73iIXRiwvzc hN1auq8Mb0WVXJPTnLGMIMg3+NF/F7mH8oFYhNh7JvmnFwXapLLZAteEKHkkWu+i efUAU1mo2dlQcKasLUqAzcWIqg3UxW3rCGjHM6GoLnyr2C9nEf88wF3VI2FiwvxF n2hVYwsA29gZSqlpIsYNDcJZ3NKFfKlTbGxzrjaP6FN8WvsLm6BpuIV1ssDsl/gy tzEHyWVN4eJJe13QfuuSURE0FFlcpnl2rrYl60FJBnl2osNBWoepYwjjgRS0+3qL wV5BqJMpDiTekEOAmxncA/DxDEIsWqDdDGCrvcMxWd3500HvV7KsdmEbnP7CKmPF iuPvKrdZVb9QRH4Lzk0OQh/kS/pEAZjJXEy+Jgy07FlIYZs0G5DohkV/bTrU2OvX ZfOYkOk+f/D644db0WAOd2M161YEUBBPctFYcuL18nS/7sfk4jh8boWb9vqzR7G3 7vdeoGUmCwolP/kl9zMO =2l/K -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Post Session Id
-Original Message- From: Christopher Schultz [mailto:ch...@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? Jeff
Re: Post Session Id
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 3/30/15 12:19 PM, Jeffrey Janner wrote: -Original Message- From: Christopher Schultz [mailto:ch...@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. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVGYQxAAoJEBzwKT+lPKRYPZoP/iWHtCQlURZrspVAi9LvtXYw bkiJNkajkrYlPwIH5gbNXKbjMl1Y0tKkYJ2ba3+uxx80LpKOFBCCUP7dZQ1Te5tH 2VfsiidZp7VAwQAQgKw1UDCsg8lNdnFM8o6m5ClTXhIQluz6T1Acc0PBMDvdKvCE prFyYZ2q6VhVgwG0+s1sdo6DLWgLbd/aD517MNO3qrlW8vE5zmeDfWejzqLJTsA7 MfwcmjuKDuTgJwScdBd5dcCNa8D9kLoyDs9b2AWTDRwKebBQE8yqKDfqNp6eFqCI v6DdexpDZYeO0nbId6fFXbtsy9sZ3mbZmoALkGVjykxLEdRIm4gk3dDHzxRqTq8U KyGfWvIprYNfHQx5ehK1bfovfCSQ8AAz2cRg0hAj1gyDUnKVGqe+9lFBeSB/Bw9T F8FAYiBah66AVas1fEXv/MW0mmwySzDTSXhoTpm36TxF88vpQ49RPHx3F/hE6Hon JKhnB3hLwAG4ti+lhg1+fFAfnpPKqajoRbuE/UXW0AT2Uk4fXEaBh3dTZQBD46SQ iblxG498bjVuOPlMLuTOWa/Xu04sb6Eh5VO8WqcvSkXBJItFws+XUakwkMpHDpjx Y0Fa93XSczs2ryPBD62uiJrzqXxtEc2V/gNMbgn+L42KEWs5W6xQlY+gRiuDj6F0 npXdJG3SwGNX/LWdXwEl =swso -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Post Session Id
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:ch...@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 ?) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Post Session Id
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aurélien, On 3/30/15 10:21 AM, Aurélien Terrestris wrote: Thanks Christopher, I believe this was working by the time of Tomcat 4.. but not completely sure, it was a long time ago :) Even for Tomcat 4, that would surprise me. - -chris 2015-03-30 16:14 GMT+02:00 Christopher Schultz ch...@christopherschultz.net: Aurélien, On 3/30/15 4:24 AM, Aurélien Terrestris wrote: If you write a Valve (which would be Tomcat-specific, and not work under other servlet containers), you could change the way Tomcat reads session identifiers from the request (and use a request parameter instead of a path parameter). Maybe could you also have a look on Filters since they're made for modifying the request before it reaches the servlet (or modifying the response after it leaves the servlet) : http://www.oracle.com/technetwork/java/filters-137243.html This won't work well with Tomcat's authorization checks, since they occur before the filter chain in invoked. -chris 2015-03-30 9:57 GMT+02:00 Wesley Acheson wesley.ache...@gmail.com: 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. For this purpose I'd like to post some value around that acts as a session Id. However I'm not sure if this is possible? If you write a Valve (which would be Tomcat-specific, and not work under other servlet containers), you could change the way Tomcat reads session identifiers from the request (and use a request parameter instead of a path parameter). I understand that the solution at the moment would be container specific. Or you could handle session-management yourself and not use servlet-spec-style session-tracking (which would be WAY more invasive to your application). In the longer term this is probably better. For the immediate term I just need the lease invasive approach for the application. *I'm aware that this won't work for common paradigms such as POST-REDIRECT-GET.* Looking at CoyoteAdaptor.java seems to suggest that session Id can only be retrieved using SSL COOKIE and URL. COOKIE is out because of third party issues. URL is out because of compliance. SSL may be a possiblity but only if it doesn't involve custom client certificates. Is there any good place to hook in a post parameter for retrieving and reattaching the session? I've not done this before. CoyoteAdapter calls request.setRequestedSessionId in a few places, and I don't believe CoyoteAdapter can be overridden or replaced directly. If you had a Valve that ran before anything else, you might be able to capture the request, read a request parameter, and then call setRequestedSessionId yourself with that replacement value. Thanks very much I'm going to read up on valves now. YMMV -chris - - --- - - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --- - -- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVGXJ6AAoJEBzwKT+lPKRY+koP/iaTP1QqkqgesJkLiSsuJBq8 wAt9ftVDWHDn4+QteaM8ZCO6xOTr8igOBJn0aAXua69YX/5iHcIgZsxGBh272ZpF XzUU8cPP2dpzLwlM/SvhJfqYuIRyK/D6HVdF3/M8RGmc6uZSzNeSPnrvgp0ZB/dt zaiAIMlf9QZzqE+7g0OHAtq1XhBYYWyHSfJtqFr6uV6ifFwTTZqjHrQc77otQzNn CU6c5QreGuB13gSEAjs8elBJ29xih/rzkRuch5qigs0uI4zr/nj06Lh18Xv9CnBf l17SKyqvAc6RoNhMg7PEx7pJQKyVkcHobtsXcV0/08B0SZiEDc9dX95YraNBdZ+l EjRbkYAVsm8fTr6Vqna4rq6J9+uHZkbJ0Tauh4uqf5ApFK1iQmOR+E4WHn6lxloq MZOfkM4jNQVgpje1lGz+YfQ/F+H1tSDhpZDvkIBlQ3hDPXVBrUWuM2btEQfrpfIK auM1oFnc484NhKoePg1h4rIsW68sx8Q1sbs6GO5mlynNmah7eqFanvwalocjjmcc
Re: Post Session Id
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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 . For this purpose I'd like to post some value around that acts as a session Id. However I'm not sure if this is possible? If you write a Valve (which would be Tomcat-specific, and not work under other servlet containers), you could change the way Tomcat reads session identifiers from the request (and use a request parameter instead of a path parameter). Or you could handle session-management yourself and not use servlet-spec-style session-tracking (which would be WAY more invasive to your application). *I'm aware that this won't work for common paradigms such as POST-REDIRECT-GET.* Looking at CoyoteAdaptor.java seems to suggest that session Id can only be retrieved using SSL COOKIE and URL. COOKIE is out because of third party issues. URL is out because of compliance. SSL may be a possiblity but only if it doesn't involve custom client certificates. Is there any good place to hook in a post parameter for retrieving and reattaching the session? I've not done this before. CoyoteAdapter calls request.setRequestedSessionId in a few places, and I don't believe CoyoteAdapter can be overridden or replaced directly. If you had a Valve that ran before anything else, you might be able to capture the request, read a request parameter, and then call setRequestedSessionId yourself with that replacement value. YMMV - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVGJYFAAoJEBzwKT+lPKRYn8oP/0LIWZKl5Nf/bYdN1BeosGFF 6hLS/mEDZ+XUD/NMpGpTHjoin3+32m7kGKEGCCApQDc4GAUlIwJGzLeLPsGfFaoo QXXyM6XUfpHWmJaEPtAySe0CZ/fwOKvL/DKuuO7UbtjFmNc8Pm/e87p5lmprsaQ1 C+4pfXsV5ltdDO8eZU0ofOHAXA0qkDuizeixwEcG3sXnNqF4Hr7Oq4gF0TKwCAU9 6Hce0NYVY61YY64U0m+dCCsH5a9hMUlu48YGDA9JemKmeNLexR3TrxFC8LT8iqUW jXNygDD7GBfFBhIiYujUo3HwSCNW091OMy6Vb0DhcSOlL11LVpK2+eNLZ1aM3kHI 881Onen2evMjzZ3PcALw2SqN3Cmr8dqMp0YhrJc2jsZ6OXBrYSuSCYCw4A0tDlN7 GTusoqFobmipgXu+sksZh5A6h5uyThVTLikG3CQ72wvTDMzRBh1YrNPc027BLuKN k/KOoBv3Lkyan+pSEbzQCCchB2IQ/CSFHoD8jgfzcHehJ5qB1Mrwo97kwsh1qbvk IjGssbqyDrTmfrKVyl1ypeCi18l7pn9GrTzJwFoNUxmfd+42elwCrRPUdCYYZuR8 9Ne8uYegBwnvRQpDN5RCK73Bqpyi2lgyP10Ph20TvnQ3ACDNbb6247TOTPGnItGr G5g/FyojfAtvlnhe7+r4 =0axs -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Post Session Id
Hi All, 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. For this purpose I'd like to post some value around that acts as a session Id. However I'm not sure if this is possible? *I'm aware that this won't work for common paradigms such as POST-REDIRECT-GET.* Looking at CoyoteAdaptor.java seems to suggest that session Id can only be retrieved using SSL COOKIE and URL. COOKIE is out because of third party issues. URL is out because of compliance. SSL may be a possiblity but only if it doesn't involve custom client certificates. Is there any good place to hook in a post parameter for retrieving and reattaching the session? Regards Wesley
