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