Wesley Acheson wrote:
Because if they are reverse proxying on a subdomain then the subdomain
needs a ssl cert basically.
I am not very bright, so I am still struggling a bit to understand the
architecture.
(And I'll stop whenever you tell me to.)
The reason for me to follow-up on this for now, is that I have some experience in terms of
trying to play the "man-in-the-middle" kind of thing, by modifying request/response
headers and/or URLs to try to make them fit into a scheme; and I know that it is not easy
and can easily lead to dead-ends, particularly when you have to deal with redirects
in-between (think Google ads, client-IP checking stuff, akamai etc..).
So basically, the simpler you can keep the scheme, the better.
In this case, I am imagining the following :
- multiple clients access multiple sites of the main entity, via HTTPS.
- the entity returns a "homepage" which contains an <iframe>, said <iframe> being in fact
your own Tomcat application, which requires sessions, and this is what is not working
correctly at the moment, because of the "third-party cookie" issues described previously.
- I previously suggested that to resolve this, it would be feasible to have the <iframe>
document itself appear to reside on the same site as the entity homepage, and this
homepage server then acting as a proxy to your own site.
To which your answer (if I understand correctly) is that, if the main sites need to proxy
to multiple sites of your application, this would require a cert for each of those
websites (yours).
So obviously (or not) there is a requirement that if they proxy to you, this proxy
connection also has to happen under HTTPS (which, technically, is a choice, not an
obligation. It could perfectly be so that the dialog between the user browser and the main
site is HTTPS, but the dialog between the main site and your application server is pure
HTTP (or AJP)). But let's say for now that it must be encrypted.
There are several ways in which this could be done, without requiring one cert for each of
your sites.
One way would be that the connections between the main site and your sites are simple
HTTP, but go through a pre-established SSH tunnel to your servers.
(or a VPN).
Another way would be that when the main sites proxy to your sites, they do it in such a
way that they address always the same site on your end (needing a single cert), but that
the URLs which they proxy are rewritten in such a way that they allow you, on your end, to
"redistribute" these requests to several of your sites. (*)
The main point is that the user browsers never need to see any of this. To them,
everything always comes from / goes to the same "main" website under HTTPS. Whatever
happens on that main website and beyond is none of their concern.
Even in the <iframe>, any URL or data (or cookie) that they will ever see, will always
refer to the main site.
It is a situation which is in fact very similar to a load-balancing scheme, where one
front-end HTTP server acts as a load-balancer for any number of back-end Tomcats.
And the logic and the software to do that already exist and work well.
(*) In other words :
- the clients access https://www1.domain1.org/URL
https://www2.domain2.com/URL
- the server at www1.domain1.org proxies this to
http(s)://yourfront-end.yourdomain.com/site1/original-URL
- the server at www2.domain2.com proxies this to
http(s)://yourfront-end.yourdomain.com/site2/original-URL
- your server yourfront-end.yourdomain.com proxies this further back to
either
- yourtomcat1.yourdomain.com/original-URL
or
- yourtomcat2.yourdomain.com/original-URL
(or whatever)
and the responses go back the opposite way.
The point being that the only server which (possibly) needs a cert is
yourfront-end.yourdomain.com.
And all the rest is standard Apache httpd and Tomcat configuration, no special Valves or
Filters required.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
