> -----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 - 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 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. Terry �������܀�...@�ĸĜ�p���ɽ�ѕ��������̽������������ѥ������������������4)%��$�ɕ�ɕ͠�ѡ�������ѡ���������������̰���Ёѡ�ɔ��́�ѥ������������4(4(����$����ѥ���������ɔ�ѡ�Ё$�������ɥ�����ѡ�������́���������4(������݅́Ѽ4(���������ѡ������ѕȁ��Ё���ѡ��݅䀴�ѡ���ձ��������ȁ�ɽչ��ѡ�́�����4(�����́��ɔ�����l�t4(���4(������������Ѐ��͕��Ԝ�������д����������Ȁ�...@�ĸĜ�p�4(�����х͕�ٱ����ѥ���х������������������������4(������������Ѐ��������д����������Ȁ�...@�ĸĜ�p�4(����ɽ�ѕ�������Ց�̽����Ʌ����̀��������� �������4(������������Ѐ��������д����������Ȁ�...@�ĸĜ�p�4(����ɽ�ѕ�������Ց�̽�����̀��������� �������4(������������Ѐ��������д����������Ȁ�...@�ĸĜ�p�4(����ɽ�ѕ�������Ց�̽�չ�ѥ��̹�̀��������� �������4(������������Ѐ��������д����������Ȁ�...@�ĸĜ�p�4(����ɽ�ѕ�������Ց�̼Ĺ�̀��������� �������4(������������Ѐ��������д����������Ȁ�...@�ĸĜ�p�4(����ɽ�ѕ�������Ց�̼ȹ�̀��������� �������4(������������Ѐ��������д����������̀�...@�ĸĜ�p�4(����ɽ�ѕ�������Ց�̼̹�̀��������� �������4(��4(�����聅���ѡ��ͅ����������م�Ք���4(��4(������������Ѐ��������д����������Ѐ�...@�ĸĜ�p�4(����م͍ɥ��͕�ٱ���ɕ�Օ��������̀��������� �������4(��Q��ɔ��́�����������ͱ�͠����ѡ�ЁUI0�ݡ��������́�չ���Ѽ�����%Н�4(��չ�������Ѽ����ѡ���ɽ��������Ё�Ё���х���䁑���Ё�����ɥ��и4(4)$���������ѡ���ɥ���������Н�����є���ɽȰ�ͽ���4(4(������������Ѐ��������д�������������...@�ĸĜ�p�4(����ɽ�ѕ��������̽������������Ĺ��������������Ԝ��4(������������Ѐ��������д�������������...@�ĸĜ�p�4(����ɽ�ѕ��������̽������������ȹ��������������Ԝ��4(������������Ѐ��������д�������������...@�ĸĜ�p�4(����ɽ�ѕ��������̽������������̹��������������Ԝ��4(������������Ѐ��������д�������������...@�ĸĜ�p�4(����ɽ�ѕ��������̽��������������������������Ԝ��4(������������Ѐ��������д�������������...@�ĸĜ�p�4(����ɽ�ѕ��������̽������������й��������������Ԝ��4(������������Ѐ��������д�������������...@�ĸĜ�p�4(����ɽ�ѕ��������̽������������Թ��������������Ԝ��4(������������Ѐ��������д�������������...@�ĸĜ�p�4(����ɽ�ѕ��������̽������������ع��������������Ԝ��4(������������Ѐ��������д�������������...@�ĸĜ�p�4(����ɽ�ѕ��������̽������������ܹ��������������Ԝ��4(������������Ѐ��������д�������������...@�ĸĜ�p�4(����ɽ�ѕ��������̽�������������������������Ԝ��4(������������Ѐ��������д����������Ā�...@�ĸĜ�p�4(����ɽ�ѕ��������̽������������九�������������Ԝ��4(������������Ѐ��������д����������Ȁ�...@�ĸĜ�p�4(�����х͕�ٱ����ѥ���х���������������܀����������Ԝ��4(��4(������������܁ѡ���������م�Ք� _______________________________________ 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