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. >>> 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 >>> >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
