-----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 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?
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAku+WfcACgkQ9CaO5/Lv0PCMCwCgqycIgJ+q7QBhTz+wqlsaUNjM
aDoAnRQ8dp8DC274o63btpYmBhRrh1qY
=Ng0k
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
