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