> -----Original Message----- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Friday, April 09, 2010 5:55 PM > To: Tomcat Users List > Subject: Re: Tomcat 6.0.24 requires me to log on twice > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > Terry, > On 4/9/2010 12:08 PM, Terry Horner wrote: > > There aren't any iframes or frames. The navbar does use > > document.write to add several <div>s to the page. > Good. Presumably, all this content-generation is done on page load? It > shouldn't really matter, since you're using cookies for everything.
It's generated by the included (restricted) .js file, rather than being in a function that is explicitly called in onload. But I checked and the problem occurs even if the js file is empty - which makes sense, as the problem is with accessing the file rather than what is done with it. > > (1)user sees first logon page, with image > > (2) they logon, see the data page, but without the embedded > navbar, the request for which is met with a logon page (not > displayed because the browser expects a .js file) > > (3)user requests a different page, and are told to login again > > (4)they do, the system logs them on, gets the navbar > request, logs them on again without the user doing anything > (???), then from this point they have a normal user experience > > > > #Fields: c-dns x-H(remoteUser) date time x-H(protocol) > cs-method cs-uri sc-status cs(Cookie) x-P(j_username) > > #Version: 2.0 > > #Software: Apache Tomcat/6.0.26 > > (1) > > localhost - 2010-04-09 15:32:14 'HTTP/1.1' GET > /dataservlet1?timestamp=1205168884309 200 - > > localhost - 2010-04-09 15:32:15 'HTTP/1.1' GET > /frontend/images/image1.gif 200 '08E40C3900' > > (2) > > localhost - 2010-04-09 15:32:19 'HTTP/1.1' POST > /j_security_check 302 '08E40C3900' > Okay, that all looks normal. Note the 302 response which is directing > the client to re-request the original URL: > > localhost 'user75' 2010-04-09 15:32:22 'HTTP/1.1' GET > /dataservlet1?timestamp=1205168884309 200 - > Hmm... no cookie included with this request. I wonder why. Looking at old logfiles from slightly older tomcat 6.0 versions this seems to be normal - this request in the last step in the request data page->get sent to logon page->send username and password->get forwarded to data page process. The original request to dataservlet1 didn't have a cookie assigned, so this one doesn't either. > > localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET > /frontend/includes/functions.js 200 '08E40C3900' > > localhost - 2010-04-09 15:32:24 'HTTP/1.1' GET > /javascriptservlet?request=common.js 200 '08E40C3900' > Old (stale) session id :( > > localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET > /frontend/images/global/logo.gif 200 'B5F7F32D85' > > (3) > New session id. This request was made 30 seconds after the > previous one. > Is this the same client? Yes, this is on a test system, with only one user on at time. > > localhost - 2010-04-09 15:33:02 'HTTP/1.1' GET > /dataservlet2?timestamp=1270827182637 200 'B5F7F32D85' > > localhost - 2010-04-09 15:33:02 'HTTP/1.1' GET > /frontend/images/global/image1.gif 200 'B5F7F32D85' > > (4) > > localhost - 2010-04-09 15:33:06 'HTTP/1.1' POST > /j_security_check 302 'B5F7F32D85' > Another login interception (to /dataservlet2, probably) and > redirect to original URL. > > localhost 'user75' 2010-04-09 15:33:06 'HTTP/1.1' GET > /dataservlet2?timestamp=1270827182637 200 'B5F7F32D85' > Authentication in this case doesn't appear to have switched > the session id. The original request to dataservlet2 had a cookie assigned, so this one does too. (Is my interpretation. I'm far from sure) This may have something to do with why this logon works. The request for dataservlet1 above doesn't have a cookie, and doesn't stick, this request does have a cookie, and does stick (albeit with a different session ID) If you log on, go through this process, log off again, then log on again there isn't a problem - my theory is that this is because when you are logged off there is still a JSESSIONID cookie present (it points at an invalid session), and that somehow everything works if you send a JSESSIONID cookie, nomatter what its value. (By 'stick' I mean that from this point all resources are shown correctly and the user isn't shown the logon screen again) If I am right here I'm not entirely sure why. > > localhost 'user75' 2010-04-09 15:33:08 'HTTP/1.1' GET > /javascriptservlet?request=common.js 200 'E892F3EB0B' > > and from here on all requests use the E892F3EB0B cookie > ...which appears to be the re-assigned session id for the login > associated with the B5F7F32D85 session id. > > That's all very weird. What's your session timeout? I'm > wondering why at > 2010-04-09 15:33:00 there was a "bare" request for an image, and then > why there was no session id accompanying the request for /dataservlet1 > at 2010-04-09 15:32:22. The session timeout is 30 minutes. I mentioned before that I had abridged the access log - my aim was to keep the clutter out of the way - the full log for around this point is more like localhost 'user75' 2010-04-09 15:32:22 'HTTP/1.1' GET /dataservlet1?timestamp=1205168884309 200 - - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/general.css 200 '08E40C3900' - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/ie.css 200 '08E40C3900' - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/functions.js 200 '08E40C3900' - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/1.js 200 '08E40C3900' - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/2.js 200 '08E40C3900' - localhost - 2010-04-09 15:32:23 'HTTP/1.1' GET /frontend/includes/3.js 200 '08E40C3900' - localhost - 2010-04-09 15:32:24 'HTTP/1.1' GET javascriptservlet?request=common.js 200 '08E40C3900' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/image1.jpg 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/image2.gif 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/image3.gif 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/logo.gif 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/image4.gif 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/image5.jpg 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/image6.gif 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/image7.jpg 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:00 'HTTP/1.1' GET /frontend/images/global/image8.gif 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:01 'HTTP/1.1' GET /frontend/images/global/image9.gif 200 'B5F7F32D85' - localhost - 2010-04-09 15:33:02 'HTTP/1.1' GET /dataservlet2?timestamp=1270827182637 200 'B5F7F32D85' - so I don't think this is anything unusual - my interpretation is that the dataservlet1 page is delivered to the browser (at this point the user has completed their first login) which the goes through requesting images and javascript files one by one. There is a pause when it requests the navbar and the server doesn't think the user has logged on, and then the remaining resources are loaded. The last line above is the user's next request. > > Terry > That looks weird :) > - -chris Yes it did, I'm not sure what that was Terry .which appears to be the re-assigned session id for the login > associated with the B5F7F32D85 session id. > > That's all very weird. What's your session timeout? I'm > wondering why at > 2010-04-09 15:33:00 there was a "bare" request for an image, and then > why there was no session id accompanying the request for /dataservlet1 > at 2010-04-09 15:32:22. The session timeout is 30 minutes. I mentioned before that I had abridged the access log - my aim was to keep the clutter out of the way - the full log for around this point is more like localhost 'user75' 2010-04-09 15:32:22 'HTTP/1.1' GET /dataservlet1?timestamp=1205168884309 200 - - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/general.css 200 '08E40C3900' - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/ie.css 200 '08E40C3900' - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/functions.js 200 '08E40C3900' - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/1.js 200 '08E40C3900' - localhost - 2010-04-09 15:32:22 'HTTP/1.1' GET /frontend/includes/2.js 200 '08E40C3900' - localhost - 2010-04-09 15:32:23 'HTTP/1.1' GET /frontend/includes/3.js 200 '08E40C3900' - localhost - 2010-04-09 15:32:24 'HTTP/1.1' GET javascriptservlet?request=common.js 200 '08E40C3900' _______________________________________ The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. This mail and any attachments have been scanned for viruses prior to leaving the Dancerace network. Dancerace plc will not be liable for direct, special, indirect or consequential damages arising from the alteration of the contents of this message by a third party or as a result of any virus being passed on. Dancerace plc reserve the right to monitor and record e-mail messages sent to and from this address for the purpose of investigating or detecting any unauthorised use of its system and ensuring its effective operation. _____________________________________________________________________ This message has been checked for all known viruses by UUNET delivered through the MessageLabs Virus Control Centre. For further information visit http://www.uk.uu.net/products/security/virus/
****** Message from InterScan VirusWall 6 ****** ** No virus found in attached file noname.htm InterScan VirusWall 6 has scanned this message and found it to be free of known viruses. ***************** End of message ***************
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
