tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: request.login() not persistent
Date Fri, 06 Apr 2012 15:33:31 GMT
Hash: SHA1


On 4/5/12 6:11 PM, Jerry Malcolm wrote:
> Konstantin,
> I was using:
> <META HTTP-EQUIV="Refresh" CONTENT="0; URL=/userhome">
> I changed it per your comment to:
> <%  response.sendRedirect( response.encodeRedirectURL( "/userhome"
> )); %>

A more minimal change would have been this:

response.encodeURL("/userhome") %>">

I always use request.getContextPath() + ... when building URLs, too:
that makes them relocatable. So the entire incantation would be:

response.encodeURL(request.getContextPath() + "/userhome") %>" />

(I used <meta /> as an XHTML tag instead of <meta>, there. I dunno
what your content-type actually is, though).

You'll also want to make sure that your login <form> encodes any
session id information into the "action" attribute, in case a session
already exists. Otherwise, your webapp won't work unless cookies are

> It's working now, but I have no clue what's going on.

Read the javadoc for HttpServletResponse.encodeURL and

> But I am apparently missing something major here, and I want to
> understand this.  So please educate me a bit...

Your client probably does not have the session id after you call
login(). The javadoc for login() doesn't say anything about
communicating a session id to the client, and I couldn't find in the
spec document itself any mention of cookies and the login() method
(though I didn't look terribly hard).

I suspect that login() does not automatically set a "Set-Cookie"
header on the response: you may have to do that yourself. You can tell
easily by rolling-back your changes and looking at the HTTP traffic
between your client and server during the login/login-again conversation.

> I completely understand the session philosophy and how the logon
> state is maintained in the session.  When it was failing the
> session id did not change between the logon page and the redirect
> target page.

As measured by what?

> So I'm assuming the session wasn't dropped.  It's like the logged
> on state was not saved in the session object.

According to the servlet spec, having a session and being logged-in
are equivalent, as long as authentication has occurred once for form

> 1) The <meta... html tag simply tells the browser when it reads the
> page to 'try again' at the new URL.  In my mind that is no
> different from the user responding to something on a page and
> submitting a request for a new page. Why is the session logged-on
> state information somehow lost in that interaction when it is
> maintained if the user just hits a button and goes to another
> page?

Possibly because you are not properly encoding the session id in the
URL, coupled with loss or absence of the session cookie being sent in
the response.

> 2) I assume the response.sendRedirect( ) with the encoded URL sends
> one of the 301 or 303 or something response codes back, right?  In
> either case, <meta... or 30x response code, why is the session info
> lost in one and not the other?

See above.

> 3) The biggest concern I have is that it worked for several months
> on one machine with the <meta... tag coding.  If it worked, then it
> stopped, now it works again, and I don't know why, my assumption is
> that it's going to stop working again for me sometime in the
> future.  What could I have done that made it work at one time on
> one machine and then stop?

There could be several reasons, but the easiest thing that could have
happened, as Chuck suggests, is that cookies were disabled on the client.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message