-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jerry,
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:
<META HTTP-EQUIV="Refresh" CONTENT="0; URL=<%=
response.encodeURL("/userhome") %>">
I always use request.getContextPath() + ... when building URLs, too:
that makes them relocatable. So the entire incantation would be:
<META HTTP-EQUIV="Refresh" CONTENT="0; URL=<%=
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
enabled.
> It's working now, but I have no clue what's going on.
Read the javadoc for HttpServletResponse.encodeURL and
HttpServletResponse.encodeRedirectURL.
> 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
authentication.
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9/DMsACgkQ9CaO5/Lv0PDQrgCgttz9YAJh0E/Irq0cupx/kO1o
ElAAn1mfiiQr90SU3pw9LMf95l41rzl+
=HMeM
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
