• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How does jSecurityCheck know which page was requested ?

 
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

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.

Thanks very much
 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sol Mayer-Orn
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you so very much.
This valuable info appears to be quite hard to get.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic