RE: Tomcat 6.0.24 requires me to log on twice
-Original Message- From: Terry Horner [mailto:t.hor...@dancerace.com] Sent: Friday, April 09, 2010 5:08 PM To: users@tomcat.apache.org Subject: RE: Tomcat 6.0.24 requires me to log on twice -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, April 08, 2010 11:35 PM To: Tomcat Users List Subject: Re: Tomcat 6.0.24 requires me to log on twice -BEGIN PGP SIGNED MESSAGE- Does your webapp's code do anything with cookies and/or inspecting the session? - -chris Not with the JSESSIONID cookie, its adds other cookies with response.addCookie(), and reads those cookies, but doesn't modify any. [...] However, the application does copy headers from a request it forwards on. And it was copying these using setHeader(), when it should have been using addHeader(). As one of the headers was the Set-Cookie header this meant the app was overwriting the Set-Cookie header for JSESSIONIDSSO (and doing something similar if SSO was disabled). For some reason (change 45255?) this behaviour worked fine on Tomcat 6.0.20, but not later versions. I have corrected the code and now everything runs smoothly. Thanks for your help here. Terry ___ 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
RE: Tomcat 6.0.24 requires me to log on twice
No, the logon page is very simple, without the navigation bar, so it doesn't link that page -Original Message- From: Pid * [mailto:p...@pidster.com] Sent: Friday, April 09, 2010 5:53 PM To: Tomcat Users List Subject: Re: Tomcat 6.0.24 requires me to log on twice Terry, does your login page reference the same script URL as the secured pages, by any chance? p On 9 April 2010 17:39, Christopher Schultz ch...@christopherschultz.netwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry, On 4/9/2010 12:14 PM, Terry Horner wrote: The problem seems to occur if there are any restricted resources within a page - it doesn't seems too outlandish for someone to restrict access to their images folder (say, it has client logos in it and they are required to be a bit paranoid about their client list). If you have a restricted images folder, why are you trying to serve images out of it onto a non-restricted page? I have a workaround that will work for some people in this situation - require all logons to go through index.jsp (or whatever) and have this be a page that just shows a 'loading...' animated image (or whatever) - but this doesn't work if you want to be able to bookmark pages within your site. If you bookmark a restricted page, you don't even see it until after successful authentication, so there's no problem there. The problem is with including restricted content in an unrestricted page. I agree that your webapp shouldn't be suffering the kind of fate it is currently is, but you'd save yourself a lot of trouble by not doing something which seems so illogical. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAku/WDMACgkQ9CaO5/Lv0PCKagCffXehaOcXta2EFqGDPG19HnOK MkcAn2WlANst7s5vhMDk/A7Pj3WTnIe3 =b/EF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- -- pidster.com _ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk ___ 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
RE: Tomcat 6.0.24 requires me to log on twice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry, On 4/9/2010 12:14 PM, Terry Horner wrote: The problem seems to occur if there are any restricted resources within a page - it doesn't seems too outlandish for someone to restrict access to their images folder (say, it has client logos in it and they are required to be a bit paranoid about their client list). If you have a restricted images folder, why are you trying to serve images out of it onto a non-restricted page? I have a workaround that will work for some people in this situation - require all logons to go through index.jsp (or whatever) and have this be a page that just shows a 'loading...' animated image (or whatever) - but this doesn't work if you want to be able to bookmark pages within your site. If you bookmark a restricted page, you don't even see it until after successful authentication, so there's no problem there. The problem is with including restricted content in an unrestricted page. I agree that your webapp shouldn't be suffering the kind of fate it is currently is, but you'd save yourself a lot of trouble by not doing something which seems so illogical. - -chris That would be illogical, but it's not what I'm doing - in our system (and in the hypothetical example) the restricted images are inside a restricted page. The bookmarks are to a restricted page, any unrestricted pages on our system only hold unrestricted resources. ___ 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
RE: Tomcat 6.0.24 requires me to log on twice
-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 divs 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
Re: Tomcat 6.0.24 requires me to log on twice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry, On 4/12/2010 8:05 AM, Terry Horner wrote: That would be illogical, but it's not what I'm doing - in our system (and in the hypothetical example) the restricted images are inside a restricted page. The bookmarks are to a restricted page, any unrestricted pages on our system only hold unrestricted resources. I've never had anything like this happen except when I was doing things like multiple webapps deployed into the same URL space. You said this was an example: what is the context path of the real deployed webapp? Are there more than one webapp involved, here? If you have a working example, can you post a ZIP file to the list that exhibits this behavior? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDIskACgkQ9CaO5/Lv0PBG5gCfXTIvmG7546fFQz1oNfGHBvda aQAAoLqqaNj6RyTRLw177ANpUNPJphxM =YKsd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.24 requires me to log on twice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry, On 4/12/2010 9:23 AM, Terry Horner wrote: 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. No, the difference between an authenticated user and an unauthenticated one is the presence of the cookie: otherwise, the server has no idea who the client is. Without the cookie, there is no identifying information. The absence of that cookie is concerning. How are you generating this log file? Using the AccessLogValve? At what level (server or Context)? And what is your log pattern string? 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) That's what I'm thinking, but it should all be the same code. Something about your app make this different somehow. 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. No, the JSESSIONID cookie should be deleted from the client when you log out. Can you verify that this is true by looking at your web browser's cookie store during and after your session? 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' - Good: all the same cookie value ;) localhost - 2010-04-09 15:32:24 'HTTP/1.1' GET javascriptservlet?request=common.js 200 '08E40C3900' - There is no leading slash on that URL which looks funny to me. It's unlikely to be the problem, but it certainly doesn't look right. 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' - ... and now the cookie value has changed for no reason that I can see. Did you omit some of the log again? Say, an authentication attempt? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDJIEACgkQ9CaO5/Lv0PCj2wCfSO08ROQuugnz/TMATu9lAav3 z7cAnjXGz1Kj8glz8O7gYjKBMYLo3BGi =+/hi -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.24 requires me to log on twice
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Monday, April 12, 2010 2:48 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/12/2010 9:23 AM, Terry Horner wrote: 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. No, the difference between an authenticated user and an unauthenticated one is the presence of the cookie: otherwise, the server has no idea who the client is. Without the cookie, there is no identifying information. The absence of that cookie is concerning. How are you generating this log file? Using the AccessLogValve? At what level (server or Context)? And what is your log pattern string? org.apache.catalina.valves.ExtendedAccessLogValve the definition is within the host, not the context. The log pattern string is now c-dns x-H(remoteUser) date time x-H(protocol) cs-method cs-uri sc-status cs(Cookie) I have trimmed out the JSESSIONID= and any other cookies, because it used to be c-dns x-H(remoteUser) date time x-H(protocol) cs-method cs-uri sc-status x-H(requestedSessionId) cs(Referer) cs(User-Agent) time-taken cs(Cookie) and I trimmed off all of the extra stuff at the end. It seemed like changing format halfway through would be unhelpful 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) That's what I'm thinking, but it should all be the same code. Something about your app make this different somehow. 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. No, the JSESSIONID cookie should be deleted from the client when you log out. Can you verify that this is true by looking at your web browser's cookie store during and after your session? If I am on the logout.html page and do a javascript:alert(document.cookie); it shows a JSESSIONID cookie and no others (this is also true on older versions of 6.0) - the cookie store shows the same cookie. It's a new cookie, unrelated to any of the requests before it. localhost '44-000' 2010-04-12 15:10:15 'HTTP/1.1' GET /frontend/images/global/image10.gif 200 '9394BACA2D' localhost '44-000' 2010-04-12 15:10:17 'HTTP/1.1' GET /logout.html?timestamp=1271085014943 200 '9394BACA2D' localhost - 2010-04-12 15:10:17 'HTTP/1.1' GET /includes/logout.css 200 '9F16E6DAF0' localhost - 2010-04-12 15:10:17 'HTTP/1.1' GET /frontend/images/global/logoutimg.jpg 200 '9F16E6DAF0' If I refresh the page the cookie changes, but there is still a cookie. 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' - Good: all the same cookie value ;) localhost - 2010-04-09 15:32:24 'HTTP/1.1' GET javascriptservlet?request=common.js 200 '08E40C3900' - There is no leading slash on that URL which looks funny to me. It's unlikely to be the problem, but it certainly doesn't look right. I checked the original, cut'n'paste error, sorry 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
RE: Tomcat 6.0.24 requires me to log on twice
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Monday, April 12, 2010 2:40 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/12/2010 8:05 AM, Terry Horner wrote: That would be illogical, but it's not what I'm doing - in our system (and in the hypothetical example) the restricted images are inside a restricted page. The bookmarks are to a restricted page, any unrestricted pages on our system only hold unrestricted resources. I've never had anything like this happen except when I was doing things like multiple webapps deployed into the same URL space. You said this was an example: what is the context path of the real deployed webapp? Are there more than one webapp involved, here? If you have a working example, can you post a ZIP file to the list that exhibits this behavior? - -chris The webapp is one of two in a single sign-on environment, and listens on /. The other webapp is a simple one used to provide a client with a customised login page (they go to /clientname/intro.html, login through /clientname/login.jsp and, if successful are forwarded to /intro.html , which is on the main ap) However, if I remove the other application, and the SSO valve the same behaviour occours. before Context path= docBase=dabce debug=0 override=true crossContext=true reloadable=true Manager className=org.apache.catalina.session.StandardManager entropy=hiddenstuff maxActiveSessions=-1 maxInactiveInterval=1600 sessionIdLength=24 / Valve className=org.apache.catalina.authenticator.FormAuthenticator characterEncoding=UTF-8/ /Context Context path=/clientname docBase=customlogon override=true crossContext=true reloadable=true Valve className=org.apache.catalina.authenticator.FormAuthenticator characterEncoding=UTF-8/ /Context Valve className=org.apache.catalina.authenticator.SingleSignOn / after Context path= docBase=dabce debug=0 override=true reloadable=true Manager className=org.apache.catalina.session.StandardManager entropy=hiddenstuff maxActiveSessions=-1 maxInactiveInterval=1600 sessionIdLength=10 / Valve className=org.apache.catalina.authenticator.FormAuthenticator characterEncoding=UTF-8/ /Context It's difficult to trim our application down to a simple test case. I will send one when I can. Terry ___ 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
Re: Tomcat 6.0.24 requires me to log on twice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry, On 4/12/2010 11:38 AM, Terry Horner wrote: The webapp is one of two in a single sign-on environment, and listens on /. The other webapp is a simple one used to provide a client with a customised login page (they go to /clientname/intro.html, login through /clientname/login.jsp and, if successful are forwarded to /intro.html , which is on the main ap) Hmm, that could complicate things. However, if I remove the other application, and the SSO valve the same behaviour occours. That's good to know. Let's take a look. before Context path= docBase=dabce debug=0 override=true crossContext=true reloadable=true Manager className=org.apache.catalina.session.StandardManager entropy=hiddenstuff maxActiveSessions=-1 maxInactiveInterval=1600 sessionIdLength=24 / Valve className=org.apache.catalina.authenticator.FormAuthenticator characterEncoding=UTF-8/ /Context Context path= is illegal. Where did you define your Context? Context path=/clientname docBase=customlogon override=true crossContext=true reloadable=true Valve className=org.apache.catalina.authenticator.FormAuthenticator characterEncoding=UTF-8/ /Context Valve className=org.apache.catalina.authenticator.SingleSignOn / after Context path= docBase=dabce debug=0 override=true reloadable=true Manager className=org.apache.catalina.session.StandardManager entropy=hiddenstuff maxActiveSessions=-1 maxInactiveInterval=1600 sessionIdLength=10 / Valve className=org.apache.catalina.authenticator.FormAuthenticator characterEncoding=UTF-8/ /Context It's difficult to trim our application down to a simple test case. I will send one when I can. I think that would be best, honestly. Reproducibility is the most important factor when fixing issues like these. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDY1cACgkQ9CaO5/Lv0PDAFwCdEq/kq9TuXTbn65bxlt/Ag2Gs rccAoLDIUljNSh2S3+nRUcAWnYDyYs+j =Tf8U -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.24 requires me to log on twice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry, On 4/12/2010 11:23 AM, Terry Horner wrote: org.apache.catalina.valves.ExtendedAccessLogValve the definition is within the host, not the context. The log pattern string is now c-dns x-H(remoteUser) date time x-H(protocol) cs-method cs-uri sc-status cs(Cookie) I have trimmed out the JSESSIONID= and any other cookies, because it used to be c-dns x-H(remoteUser) date time x-H(protocol) cs-method cs-uri sc-status x-H(requestedSessionId) cs(Referer) cs(User-Agent) time-taken cs(Cookie) and I trimmed off all of the extra stuff at the end. It seemed like changing format halfway through would be unhelpful Okay. Check to see if these is a discrepancy between cs(Cookie), x-H(requestedSessionId), x-H(requestedSessionIdFromCookie), x-H(requestedSessionIdValid). Also, you might want to use Wireshark or something else to verify that there's only one JSESSIONID cookie being sent. If you have two cookies with different ids (which can happen if they have different paths), that'll screw things up. No, the JSESSIONID cookie should be deleted from the client when you log out. Can you verify that this is true by looking at your web browser's cookie store during and after your session? If I am on the logout.html page and do a javascript:alert(document.cookie); it shows a JSESSIONID cookie and no others (this is also true on older versions of 6.0) - the cookie store shows the same cookie. It's a new cookie, unrelated to any of the requests before it. localhost '44-000' 2010-04-12 15:10:15 'HTTP/1.1' GET /frontend/images/global/image10.gif 200 '9394BACA2D' localhost '44-000' 2010-04-12 15:10:17 'HTTP/1.1' GET /logout.html?timestamp=1271085014943 200 '9394BACA2D' localhost - 2010-04-12 15:10:17 'HTTP/1.1' GET /includes/logout.css 200 '9F16E6DAF0' localhost - 2010-04-12 15:10:17 'HTTP/1.1' GET /frontend/images/global/logoutimg.jpg 200 '9F16E6DAF0' If I refresh the page the cookie changes, but there is still a cookie. JSPs will create a session (and therefore a JSESSIONID cookie) unless they are declared with @page session=false @. Are you hitting any dynamic resources from your logout page? No, I wanted to make sure everything was there. I assumed it had changed as a result of the javascriptservlet request somehow - the javascript doesn't normally take 36 seconds to reach the browser. Heh, yeah, that's pretty unreasonable. I think it might be time to look at the HTTP conversation that's going on. That's the only way I found out that I had two cookies with different paths fighting each other. :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvDZUIACgkQ9CaO5/Lv0PDSNgCfaCNNHumDZx8Zcbw+J5anqCqh ewAAn01t0XMHuDFgpmy1Cd3MgOj1pyNH =omST -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.24 requires me to log on twice
On 08/04/2010 23:34, Christopher Schultz wrote: This happens on Tomcat 6.0.24 and 6.0.26, but not 6.0.20, which makes me think it is related to change 45255 (Provide protection against session fixation by changing session ID automatically on authentication.), in the dev environment tomcat is running on windows XP. Session tracking is done by cookie, not URL rewriting. I haven't read the actual patch that added this session-id switching but it's not clear if it's configurable. Mark said he'd likely make this an option that defaults to off. Security trumped compatibility in this case and it defaults to on. Nothing stopping you turning it off though. I'd note that apps that have issues with this behaviour are likely to have issues with load-balancing, sticky sessions and fail-over as exactly the same code is used to change the session ID on fail-over. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 6.0.24 requires me to log on twice
Hi, thanks for the analysis -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, April 08, 2010 11:35 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/8/2010 9:12 AM, Terry Horner wrote: I am having a problem with Tomcat - if I log on to a page which contains a restricted resource, it shows me the page (and any unrestricted images, etc), but doesn't show the restricted resource (I believe tomcat thinks the user is not authenticated as sends the 403 page, judging by the 3478b size of the request). That sounds about right: if you have a page like this: /unrestricted/index.jsp: html img src=%= response.encodeURL(request.getContextPath() + /restricted/sample.gif) % / /html Then your /unrestricted/index.jsp will display and the image will be broken. Note that Tomcat, in response to the request for /restricted/sample.gif will store that request and respond with a login form. When I move on to another page (or reload the same page) I am sent to the logon screen again, after I logon from here everything works as it should. So, if you go to /unrestricted/index.jsp, then hit RELOAD you get a login form? That's weird. The page that contains the restricted resource is also restricted (it's one of various pages of account information, with a navbar made with dynamically-generated javascript) Sorry, I didn't make that clear. The protected resource is some javascript, it is dynamically created as it varies from user to user. What should the behaviour be for this resource is the user is not logged-in? Can you simply make that particular resource non-restricted? That would seem to be the easiest solution. If they aren't logged in they shouldn't be able to see it. The navigation options vary a lot from user to user. I could make it non-restricted and only show the options that all users have access to when viewed by a user who isn't logged on, but this would mean the user saw different navigation options on the first page and the second, which would be a more interesting user experience than I had hoped for. This happens on Tomcat 6.0.24 and 6.0.26, but not 6.0.20, which makes me think it is related to change 45255 (Provide protection against session fixation by changing session ID automatically on authentication.), in the dev environment tomcat is running on windows XP. Session tracking is done by cookie, not URL rewriting. I haven't read the actual patch that added this session-id switching but it's not clear if it's configurable. Mark said he'd likely make this an option that defaults to off. I have bosses pushing for this to be used, so a workaround beats switching it off, if that's possible. Below is a(n abridged) snapshot of the access log, the last field is the cookie sent by the browser dataservlet1, dataservlet2 and javascriptservlet are restricted to logged on users, nothing under /frontend has any security constraints. The sequence of events, from the browser end is (1) A request is made to dataservlet1 (2) The user logs in (and tomcat rewrites the cookie) (3) Is forwarded to the dataservlet1 page, frontend resources are displayed, but the javascriptservlet is not, as it has been requested with the old cookie (this happens on ie and firefox, so doesn't appear to be a browser issue), the apparent attempt to logon for the javascriptservlet also throws another cookie into the mix (4) Another page is requested (5) The user is sent to the login page (6) They log in again (getting a third cookie), and from this point everything is ok #Fields: c-dns x-H(remoteUser) date time x-H(protocol) cs-method cs-uri sc-status bytes x-H(requestedSessionId) #Version: 2.0 #Software: Apache Tomcat/6.0.26 (1) localhost - 2010-04-08 12:25:33 'HTTP/1.1' GET /dataservlet1?timestamp=1205168884309 200 3478 - That looks like it presented a login page (3478 bytes, right?). Yes, that's right localhost - 2010-04-08 12:25:33 'HTTP/1.1' GET /frontend/images/image1.gif 200 125 '6A193109AA' (2) Given the timestamp, this was a request for a resource linked from the login page itself. localhost - 2010-04-08 12:25:42 'HTTP/1.1' POST /j_security_check 302 - '6A193109AA' Login attempt. Yes and yes localhost - 2010-04-08 12:25:42 'HTTP/1.1' POST /j_security_check 302 - '6A193109AA' (3) Second login attempt: note the cookie from the client is the same each time. The timing looks strange to me: why two simultaneous login attempts? That was a javascript error in the onsubmit in the logon form (the onSubmit called a function to disable the button which both submitted the form an returned true. d'oh), now fixed. This hasn't fixed the overall problem though - the situation is still the same
RE: Tomcat 6.0.24 requires me to log on twice
-Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Friday, April 09, 2010 8:06 AM To: Tomcat Users List Subject: Re: Tomcat 6.0.24 requires me to log on twice On 08/04/2010 23:34, Christopher Schultz wrote: This happens on Tomcat 6.0.24 and 6.0.26, but not 6.0.20, which makes me think it is related to change 45255 (Provide protection against session fixation by changing session ID automatically on authentication.), in the dev environment tomcat is running on windows XP. Session tracking is done by cookie, not URL rewriting. I haven't read the actual patch that added this session-id switching but it's not clear if it's configurable. Mark said he'd likely make this an option that defaults to off. Security trumped compatibility in this case and it defaults to on. Nothing stopping you turning it off though. I'd note that apps that have issues with this behaviour are likely to have issues with load-balancing, sticky sessions and fail-over as exactly the same code is used to change the session ID on fail-over. Mark This doesn't affect me, but I can see it being a problem for others (unless, of course, the cause is our application doing something very strange). The problem seems to occur if there are any restricted resources within a page - it doesn't seems too outlandish for someone to restrict access to their images folder (say, it has client logos in it and they are required to be a bit paranoid about their client list). I have a workaround that will work for some people in this situation - require all logons to go through index.jsp (or whatever) and have this be a page that just shows a 'loading...' animated image (or whatever) - but this doesn't work if you want to be able to bookmark pages within your site. Terry ___ 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
Re: Tomcat 6.0.24 requires me to log on twice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry, On 4/9/2010 12:14 PM, Terry Horner wrote: The problem seems to occur if there are any restricted resources within a page - it doesn't seems too outlandish for someone to restrict access to their images folder (say, it has client logos in it and they are required to be a bit paranoid about their client list). If you have a restricted images folder, why are you trying to serve images out of it onto a non-restricted page? I have a workaround that will work for some people in this situation - require all logons to go through index.jsp (or whatever) and have this be a page that just shows a 'loading...' animated image (or whatever) - but this doesn't work if you want to be able to bookmark pages within your site. If you bookmark a restricted page, you don't even see it until after successful authentication, so there's no problem there. The problem is with including restricted content in an unrestricted page. I agree that your webapp shouldn't be suffering the kind of fate it is currently is, but you'd save yourself a lot of trouble by not doing something which seems so illogical. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAku/WDMACgkQ9CaO5/Lv0PCKagCffXehaOcXta2EFqGDPG19HnOK MkcAn2WlANst7s5vhMDk/A7Pj3WTnIe3 =b/EF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 6.0.24 requires me to log on twice
Terry, does your login page reference the same script URL as the secured pages, by any chance? p On 9 April 2010 17:39, Christopher Schultz ch...@christopherschultz.netwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry, On 4/9/2010 12:14 PM, Terry Horner wrote: The problem seems to occur if there are any restricted resources within a page - it doesn't seems too outlandish for someone to restrict access to their images folder (say, it has client logos in it and they are required to be a bit paranoid about their client list). If you have a restricted images folder, why are you trying to serve images out of it onto a non-restricted page? I have a workaround that will work for some people in this situation - require all logons to go through index.jsp (or whatever) and have this be a page that just shows a 'loading...' animated image (or whatever) - but this doesn't work if you want to be able to bookmark pages within your site. If you bookmark a restricted page, you don't even see it until after successful authentication, so there's no problem there. The problem is with including restricted content in an unrestricted page. I agree that your webapp shouldn't be suffering the kind of fate it is currently is, but you'd save yourself a lot of trouble by not doing something which seems so illogical. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAku/WDMACgkQ9CaO5/Lv0PCKagCffXehaOcXta2EFqGDPG19HnOK MkcAn2WlANst7s5vhMDk/A7Pj3WTnIe3 =b/EF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- -- pidster.com
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:
That was a javascript error in the onsubmit in the logon form (the
onSubmit called a function to disable the button which both submitted
the form an returned true. d'oh), now fixed.
That's what I was figuring. Good to know that it's fixed.
This hasn't fixed the overall problem though - the situation is still
the same, only now the logs don't show two concurrent
j_security_check requests (no surprises here).
:(
There aren't any iframes or frames. The navbar does use
document.write to add several divs 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.
Not with the JSESSIONID cookie, its adds other cookies with
response.addCookie(), and reads those cookies, but doesn't modify
any. The applications writes to and reads from the session, but
leaves creating, expiring etc sessions to the server. The paths are
all set to '/'
Ok.
(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, get's 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.
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?
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.
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.
Terry
�W2�'WB��VVB��R��f��FУ���z{C��h�+b�v���!���~)^���{^�'��y+Z��q�Ǭ�� ~�{^�'�X��Ś�^�wb��mi�^u�zz'jg��b'���q�Պ��Y�e���Ƨ��m�+z���u�.�ح���~'�
�z�'v��z��
That looks weird :)
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAku/W9YACgkQ9CaO5/Lv0PDXtACeI2f8hX5+DqdmukGrvZvko02S
0yoAnjxMhymHkxTn1le7bW1L3tAJlhrS
=TnKR
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 6.0.24 requires me to log on twice
Hi, I am having a problem with Tomcat - if I log on to a page which contains a restricted resource, it shows me the page (and any unrestricted images, etc), but doesn't show the restricted resource (I believe tomcat thinks the user is not authenticated as sends the 403 page, judging by the 3478b size of the request). When I move on to another page (or reload the same page) I am sent to the logon screen again, after I logon from here everything works as it should. The protected resource is some javascript, it is dynamically created as it varies from user to user. This happens on Tomcat 6.0.24 and 6.0.26, but not 6.0.20, which makes me think it is related to change 45255 (Provide protection against session fixation by changing session ID automatically on authentication.), in the dev environment tomcat is running on windows XP. Session tracking is done by cookie, not URL rewriting. Below is a(n abridged) snapshot of the access log, the last field is the cookie sent by the browser dataservlet1, dataservlet2 and javascriptservlet are restricted to logged on users, nothing under /frontend has any security constraints. The sequence of events, from the browser end is (1) A request is made to dataservlet1 (2) The user logs in (and tomcat rewrites the cookie) (3) Is forwarded to the dataservlet1 page, frontend resources are displayed, but the javascriptservlet is not, as it has been requested with the old cookie (this happens on ie and firefox, so doesn't appear to be a browser issue), the apparent attempt to logon for the javascriptservlet also throws another cookie into the mix (4) Another page is requested (5) The user is sent to the login page (6) They log in again (getting a third cookie), and from this point everything is ok #Fields: c-dns x-H(remoteUser) date time x-H(protocol) cs-method cs-uri sc-status bytes x-H(requestedSessionId) #Version: 2.0 #Software: Apache Tomcat/6.0.26 (1) localhost - 2010-04-08 12:25:33 'HTTP/1.1' GET /dataservlet1?timestamp=1205168884309 200 3478 - localhost - 2010-04-08 12:25:33 'HTTP/1.1' GET /frontend/images/image1.gif 200 125 '6A193109AA' (2) localhost - 2010-04-08 12:25:42 'HTTP/1.1' POST /j_security_check 302 - '6A193109AA' localhost - 2010-04-08 12:25:42 'HTTP/1.1' POST /j_security_check 302 - '6A193109AA' (3) localhost 'user75' 2010-04-08 12:25:46 'HTTP/1.1' GET /dataservlet1?timestamp=1205168884309 200 22904 '949F3A1AED' localhost - 2010-04-08 12:25:46 'HTTP/1.1' GET /frontend/includes/functions.js 200 917 '6A193109AA' localhost - 2010-04-08 12:25:46 'HTTP/1.1' GET /javascriptservlet?request=common.js 200 3478 '6A193109AA' localhost - 2010-04-08 12:25:50 'HTTP/1.1' GET /frontend/images/global/logo.gif 200 2393 'DE52CCEEE3' (4) localhost - 2010-04-08 12:26:04 'HTTP/1.1' GET /dataservlet2?timestamp=1270729564199 200 3478 'DE52CCEEE3' localhost - 2010-04-08 12:26:04 'HTTP/1.1' GET /frontend/images/image2.gif 200 125 'DE52CCEEE3' (5) localhost - 2010-04-08 12:26:07 'HTTP/1.1' POST /j_security_check 302 - 'DE52CCEEE3' localhost - 2010-04-08 12:26:07 'HTTP/1.1' POST /j_security_check 302 - 'DE52CCEEE3' (6) localhost 'user75' 2010-04-08 12:26:09 'HTTP/1.1' GET /frontend/global.css 200 3032 'D2092750B2' localhost 'user75' 2010-04-08 12:26:09 'HTTP/1.1' GET /dataservlet2?timestamp=1270729564199 200 22921 'D2092750B2' localhost 'user75' 2010-04-08 12:26:09 'HTTP/1.1' GET /frontend/includes/functions.css 200 9707 'D2092750B2' localhost 'user75' 2010-04-08 12:26:09 'HTTP/1.1' GET /javascriptservlet?request=common.js 200 5237 'D2092750B2' Other than moving the dynamically generated javascript into the main body of the page, is there a way I can stop this from happening? Terry ___ 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 ** No virus found in attached
Re: Tomcat 6.0.24 requires me to log on twice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Terry, On 4/8/2010 9:12 AM, Terry Horner wrote: I am having a problem with Tomcat - if I log on to a page which contains a restricted resource, it shows me the page (and any unrestricted images, etc), but doesn't show the restricted resource (I believe tomcat thinks the user is not authenticated as sends the 403 page, judging by the 3478b size of the request). That sounds about right: if you have a page like this: /unrestricted/index.jsp: html img src=%= response.encodeURL(request.getContextPath() + /restricted/sample.gif) % / /html Then your /unrestricted/index.jsp will display and the image will be broken. Note that Tomcat, in response to the request for /restricted/sample.gif will store that request and respond with a login form. When I move on to another page (or reload the same page) I am sent to the logon screen again, after I logon from here everything works as it should. So, if you go to /unrestricted/index.jsp, then hit RELOAD you get a login form? That's weird. The protected resource is some javascript, it is dynamically created as it varies from user to user. What should the behavior be for this resource is the user is not logged-in? Can you simply make that particular resource non-restricted? That would seem to be the easiest solution. This happens on Tomcat 6.0.24 and 6.0.26, but not 6.0.20, which makes me think it is related to change 45255 (Provide protection against session fixation by changing session ID automatically on authentication.), in the dev environment tomcat is running on windows XP. Session tracking is done by cookie, not URL rewriting. I haven't read the actual patch that added this session-id switching but it's not clear if it's configurable. Mark said he'd likely make this an option that defaults to off. Below is a(n abridged) snapshot of the access log, the last field is the cookie sent by the browser dataservlet1, dataservlet2 and javascriptservlet are restricted to logged on users, nothing under /frontend has any security constraints. The sequence of events, from the browser end is (1) A request is made to dataservlet1 (2) The user logs in (and tomcat rewrites the cookie) (3) Is forwarded to the dataservlet1 page, frontend resources are displayed, but the javascriptservlet is not, as it has been requested with the old cookie (this happens on ie and firefox, so doesn't appear to be a browser issue), the apparent attempt to logon for the javascriptservlet also throws another cookie into the mix (4) Another page is requested (5) The user is sent to the login page (6) They log in again (getting a third cookie), and from this point everything is ok #Fields: c-dns x-H(remoteUser) date time x-H(protocol) cs-method cs-uri sc-status bytes x-H(requestedSessionId) #Version: 2.0 #Software: Apache Tomcat/6.0.26 (1) localhost - 2010-04-08 12:25:33 'HTTP/1.1' GET /dataservlet1?timestamp=1205168884309 200 3478 - That looks like it presented a login page (3478 bytes, right?). localhost - 2010-04-08 12:25:33 'HTTP/1.1' GET /frontend/images/image1.gif 200 125 '6A193109AA' (2) Given the timestamp, this was a request for a resource linked from the login page itself. localhost - 2010-04-08 12:25:42 'HTTP/1.1' POST /j_security_check 302 - '6A193109AA' Login attempt. localhost - 2010-04-08 12:25:42 'HTTP/1.1' POST /j_security_check 302 - '6A193109AA' (3) Second login attempt: note the cookie from the client is the same each time. The timing looks strange to me: why two simultaneous login attempts? localhost 'user75' 2010-04-08 12:25:46 'HTTP/1.1' GET /dataservlet1?timestamp=1205168884309 200 22904 '949F3A1AED' Looks like the last authentication attempt was successful, the cookie has been changed, and the client has been redirected to the original resource (/dataservlet1?timestamp=...). localhost - 2010-04-08 12:25:46 'HTTP/1.1' GET /frontend/includes/functions.js 200 917 '6A193109AA' Given the timestamp, this looks like a resource linked from the response from dataservlet1. I can see that the session id cookie appears to be stale. localhost - 2010-04-08 12:25:46 'HTTP/1.1' GET /javascriptservlet?request=common.js 200 3478 '6A193109AA' This looks okay, other than the obviously incorrect cookie. localhost - 2010-04-08 12:25:50 'HTTP/1.1' GET /frontend/images/global/logo.gif 200 2393 'DE52CCEEE3' (4) That looks weird. Where did /that/ session id come from? Yea, at this point, it looks like everything goes to hell, except that the cookies are all the same with a third (!) session id. localhost - 2010-04-08 12:26:04 'HTTP/1.1' GET /dataservlet2?timestamp=1270729564199 200 3478 'DE52CCEEE3' localhost - 2010-04-08 12:26:04 'HTTP/1.1' GET /frontend/images/image2.gif 200 125 'DE52CCEEE3' (5) localhost - 2010-04-08 12:26:07 'HTTP/1.1' POST /j_security_check 302 - 'DE52CCEEE3' localhost - 2010-04-08 12:26:07 'HTTP/1.1' POST /j_security_check
