tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Terry Horner" <t.hor...@dancerace.com>
Subject RE: Tomcat 6.0.24 requires me to log on twice
Date Fri, 09 Apr 2010 16:08:11 GMT
Hi, thanks for the analysis

> -----Original Message-----
> From: Christopher Schultz [mailto:chris@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'WBVVB&Rf&FУ
Mime
View raw message