> -----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

Reply via email to