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