tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jerry Malcolm <>
Subject Re: request.login() not persistent
Date Thu, 05 Apr 2012 22:11:53 GMT

I was using:

<META HTTP-EQUIV="Refresh" CONTENT="0; URL=/userhome">

I changed it per your comment to:

<%  response.sendRedirect( response.encodeRedirectURL( "/userhome" )); %>

It's working now, but I have no clue what's going on.  I guess I should
just be happy and move on.  But I am apparently missing something major
here, and I want to understand this.  So please educate me a bit....  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.  So I'm
assuming the session wasn't dropped.  It's like the logged on state was not
saved in the session object.


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?

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?

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?

Thanks for the education.


On Thu, Apr 5, 2012 at 7:35 AM, Konstantin Kolinko

> 2012/4/5 Jerry Malcolm <>:
> > I am using TC 7.0 on a couple of servers.  I have id/pw fields and a
> > 'login' button at the top of all guest pages on my site.  If the user
> > clicks the login, it goes to a guest page that does the request.login()
> > method call and then redirects to a protected page.  If the login fails,
> > the normal j_security login form stuff kicks in on the protected page and
> > the user logs in the old way.
> >
> > OK, this worked on one server for several months.  It never worked on the
> > other server.  On that server, the request.login() succeeded according to
> > the logs.  But when it redirected to the protected page, the j_security
> > login form would appear.  I could log in from there and everything was
> > fine.
> > (...)
> How do you perform your redirect?
> Do you call  HttpServletResponse.encodeRedirectURL( ) to encode
> sessionid in the redirection URL?
> Form authentication relies on sessions.  If new request does not
> belong to the same session (the correct session id is not send by
> client either in URL or with a cookie) then it does not have
> authentication.
> Best regards,
> Konstantin Kolinko
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message