Konstantin, 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. Questions: 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. Jerry On Thu, Apr 5, 2012 at 7:35 AM, Konstantin Kolinko <[email protected]>wrote: > 2012/4/5 Jerry Malcolm <[email protected]>: > > 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: [email protected] > For additional commands, e-mail: [email protected] > >
