When a web-application uses "j_security_check" , where does it store the name of the original page requested by the user (the one to which user should be redirected after a successful login ) ?
For example, assuming the following scenario: 0) A web application contains a page "secret.html", which is a protected resource, declared to require login. Assume mode is "Form Based Login". 1) User tries to access page "secret.html" 2) User is re-directed to "login.jsp", fills in "j_username" and "j_password", and submits them to "j_security_check". 3) "j_security_check" checks the user/password. If they are valid, it creates a "LoginContext", and then redirects the user to the originally-requested page ("secret.html").
At least that's my understanding of how it works... The question: in step 3, how does "j_security_check" know which is the originally-requested page ("secret.html") ? I had expected it to be sotred in the session context, or at least as a request attribute/parameter. But a simple test I conducted (on Websphere), shows it's not there... I put a Filter before "j_security_check", and printed all session/request attributes, and all parameters, but so no trace of the original page name.
If it helps, Tomcat 5 implements the side trip to the login page as a forward and the info you seem to be after shows up in the Servlet 2.4 "forward" request attributes ("javax.servlet.forward.request_uri", "javax.servlet.forward.context_path", "javax.servlet.forward.servlet_path", and "javax.servlet.forward.query_string"). WebSphere 6 might be up to date enough to support this but older WebSphere versions (including 5.1) are only up to Servlet 2.3 and probably don't support Servlet 2.4 features. Also, I don't know for sure, but I suspect it is app-server specific how the container retains the original "target" request until the user finally submits the j_security_check form.
I'd like to be able to override the "target page" info in certain circumstances so if someone knows how to get at this info in a standard way (or even an app-server specific way), please post. The particular case where this would come in handy is when an application has a subset of functions that require complicated session state context (e.g. midway through some sort of wizard sequence). If the user sits on that kind of page for a while and lets the session time out, and then clicks the "next" link, I'd like to be able to intercept the target page and land them somewhere else after they authenticate. It's a bit ugly to spread that kind of logic in odd places throughout an app.
Joined: Nov 13, 2002
Thank you so very much. This valuable info appears to be quite hard to get.