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,
only now the logs don't show two concurrent j_security_check requests (no
surprises here).
I'll add a new access log for clarity
> > 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".
Yes, this is a resource on the dataservlet1 page
> > 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?
I *think* that is the cookie Tomcat sent back with the dataservlet1 page,
having automatically replaced the cookie the browser requested
> 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 302 -
> > 'DE52CCEEE3'
> > (6)
> These double-logins look funny to me.
> I have a few theories, but I need more information.
>
> Are you using javascript for anything? Perhaps for adjusting some
> information in the login form during form submission?
> Are you using iFrames or any other kind of content-inside-content
> strategies?
This is the (now-corrected) javascript, called from the logon form's onSubmit
function submitLogon(){
document.getElementById("loginbutton").disabled=true;
return true;
}
There aren't any iframes or frames. The navbar does use document.write to add
several <div>s to the page.
>
> What are the paths set to for these cookies? You ought to be able to
> sniff these via your web browser or even using something like
> wireshark.
>
> 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. The
applications writes to and reads from the session, but leaves creating,
expiring etc sessions to the server.
The paths are all set to '/'
The access log now looks like this
(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'
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/functions.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/logo.gif
200 'B5F7F32D85'
(3)
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'
localhost 'user75' 2010-04-09 15:33:06 'HTTP/1.1' GET
/dataservlet2?timestamp=1270827182637 200 'B5F7F32D85'
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
Terry
&�W2�'WB��VVB��&R��f�&�F����У� У�&R��RW6��r�f67&�Bf�"��F���s�W&�2f�"F�W7F��r6��PУ���f�&�F�����F�R��v��f�&�GW&��rf�&�7V&֗76����У�&R��RW6��r�g&�W2�"���F�W"���b�b6��fv�b֖�6�fr�6��...@У�7g&FVv�W3�РХF��2�2F�R���r�6�'&V7FVB��f67&�B�6��VBg&��F�R��v��f�&�w2��7V&�...@Р�gv�7f���7v&֗D��v�ₗ�Р��F�7V�V�B�vWDV�V�V�D'��B�&��v��'WGF��"��F�6&�VC�G'VS�Р��&WGW&�G'VS�Р��ХF�W&R&V�wB���g&�W2�"g&�W2�F�R�f&"F�W2W6RF�7V�V�B�w&�FRF�FB6WfW&��F�c�2F�F�RvR�РУ� У�v�B&RF�RF�26WBF�f�"F�W6R6����W3���R�Vv�BF�&R&�RF�У�6��fbF�W6Rf���W"vV"'&�w6W"�"WfV�W6��r6��WF���rƖ�R У�v�&W6�&��У� У�F�W2��W"vV&w26�FRF���F���rv�F�6����W2�B��"��7V7F��rF�PУ�6W76����У���6�&�0РФ��Bv�F�F�R�4U54����B6����R��G2FG2�F�W"6����W2v�F�&W7��6R�FD6����R����B&VG2F��6R6����W2�'WBF�W6�wB��F�g����F�RƖ6F���2w&�FW2F��B&VG2g&��F�R6W76����'WB�VfW27&VF��r�W��&��rWF26W76���2F�F�R6W'fW"�ХF�RF�2&R��6WBF�r�pРХF�R66W72��r��r����2Ɩ�RF��0РТ��W6W"6VW2f�'7B��v��vR�v�F���vR Т�"�F�W���v���6VRF�RFFvR�'WBv�F��WBF�RV�&VFFVB�f&"�F�R&WVW7Bf�"v��6��2�WBv�F���v��vR���BF�7��VB&V6W6RF�R'&�w6W"W�V7G2��2f��R�Т�2�W6W"&WVW7G2F�ffW&V�BvR��B&RF��BF���v��v��Т�B�F�W�F��F�R7�7FV���w2F�V����vWBw2F�R�f&"&WVW7B���w2F�V���v��v�F��WBF�RW6W"F���r��F���r������F�V�g&��F��2���BF�W��fR��&��W6W"W�W&�V�6PРТ4f�V�G3�2�F�2�Ԃ�&V��FUW6W"�FFRF��R�Ԃ�&�F�6�72��WF��B72�W&�62�7FGW272�6����R������W6W&��R�Т5fW'6����"� Т56�gGv&S�6�RF��6B�b��#`Т��Ц��6Ɔ�7B�#�B��S�3#�Bt�EE��s^��ڮ���M:�v�wm9w�x���ݽ<������}��{^�����^��镨����"{^�'�&�y+Z��q�*'���N�����w(v)��
��z{C��h�+b�v���!���~)^���"{^�'�&�y+Z��q�Ǭ�� ~�&"{^�'�X��Ś�^��������wb��mi�^u��zz'jg��b'���q�Պ��Y�e���Ƨ��m�+&z����u�.�ح���~����'�
�z�'v��z��
_______________________________________
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/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
