-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nikita,
On 3/21/2010 4:34 PM, Nikita Tovstoles wrote: > Looking for someone to either confirm or refute my theory that > deploying two iframes pointing to two different stateful pages on the > same domain can lead to JSESSIONIDs being overwritten. Your JSESSIONID cookies should not interfere with each other. > http://www.foo.com/page1 > and > http://www.foo.com/page2 Are those two separate webapps? If so, they'll have different JSESSIONID cookies (with associated path) from each other. > 2. assume www.foo.com is a single host running a Tomcat (6.0.20, fwiw) > that uses JSESSIONID for session id's. Do you have anything like SSO enabled? Of course, that would make the question moot, as the cookie paths would both be '/' and the JSESSIONID would be valid for all webapps in the host/cluster. > 3. suppose these pages are turned into two iframe widgets to be > embedded on 3rd party sites: <iframe src=" http://www.site.com/page1"; > /> (and /page2 respectively) > 4. suppose there a 3rd party site that wishes to place both widgets on > the same page at http://www.bar.com/foowidgets.html As far as the server is concerned, the fact that the two iframes are embedded on a single page is irrelevant: the server gets two distinct requests: one for /page1 and one for /page2. > Can the following race condition occur? > > 1. a new visitor goes to http://www.bar.com/foowidgets.html > 2. browser starts loading URLs in foowidgets.html including the two > iframe 'src' URLs > 3. because browsers open multiple concurrent connections against the > same host (afaik up to 6 in chrome/ff case) the browser happens to > simultaneously issue requests for http://www.foo.com/page1 and > http://www.foo.com/page2 Okay. > 4. The tomcat @ foo.com receives both requests at about the same time, > calls getSession() for the first time (on two different threads) and > lazily creates two HttpSessions and, thus, two JSESSIONIDs, with > values $Page1 and $Page2. The requests also stuff data into respective > sessions (that data will be required to process subsequent requests) Correct, except that I don't think the sessions are created lazily: they should be created when you request them. > 5. assume that the browser first receives response to the page1 > request. Browser sets cookie JSESSIONID=$Page1 for HOST www.foo.com ...with path=/page1 > 6. next response to the page2 request is received and the browser > overwrites cookie JSESSIONID for HOST www.foo.com with $Page2 ...with path=/page2 > 7. user clicks on something in 'page1' iframe on foowidgets.html; > browser issues 2nd request to > http://www.foo.com/page1?action=doSomethingStateful. That request > carries JSESSIONID=$Page2 (and not $Page1 - because cookie value was > overwritten) No: the cookie value was not overwritten if the webapps are distinct. The URLs /page1 and /page2 are ambiguous with regard to distinct-ness: are they two separate servlets running in a single container (in which case the JSESSIONID should be shared, and overwriting may be a possibility) or are they two different contexts with separate context paths? > Can the above happen? I think so, but would appreciate a confirmation. > > If the above is clearly possible, what are some solutions given that > we'd like to support multiple iframes per page? We don't have a firm > need for the iframes to share the same HttpSession, though that would > be nice. In the event that the solution will still stipulate a > separate HttpSession per iframe, it is - of course - mandatory that > iframe 1 does not end up referencing httpSession state for iframe 2 > instead of own. You can always disable the use of cookies and rely on URL rewriting. > off top of my head I can think of: > > 1. map page1 and page2 to different domains (ops overhead) > 2. use URL rewriting and never cookies (messes up analytics) Does it? > 3. anything else? Separate the pages into two separate webapps? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkupML8ACgkQ9CaO5/Lv0PCoRgCgglHZz/GI5pcPGKkqy9swrhZl 3HgAnAgR2wbsbS8quSI2AJVODAp/hSm6 =nJVq -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
