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 be solved, if the content of the <iframe> appeared to the > browser as also come from "serverA.domainA.com" (like the main window's > content), wouldn't it ? > > If so, why not make the server "serverA.domainA.com" act as a reverse > proxy for the server serverB.domainB.com, and load the <iframe> from > serverA too ? > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
