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