-----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
