1

When an unauthenticated user request some resources, he will be redirected to a login page but j_security_check will keep the original requested resource. If the user login successfully, it will be redirected to that resource.

The problem is that sometimes the requested resource is dynamic, so it might not exists. I have a lot of places in my application with this behavior, so instead of validate this in each "resource handler" (controller), we are trying to centralize all this logic in a filter that intercept the j_security_check forward to the login page.

Now, how can we get the original requested resource kept by the Form-Based Authentication mechanism? It's vendor dependent?

Another alternative:

If I can run a filter BEFORE the j_security_check I can't modify the URL but I can send a redirect to the user with a "valid URL". But how can I execute a filter before the j_security_check?

ggarciao
  • 1,618
  • 16
  • 29

2 Answers2

0

Here is what you need to do:

  1. Create a filter for j_security_check in the web.xml
  2. In your Filter, before the chain.doFilter(...), change the content of the cookie named WASReqURL to redirect to a servlet which will be the post successful login.
Hesham Yassin
  • 4,341
  • 2
  • 21
  • 23
0

If pages are dynamic and "may not exist", but yet a link could have been valid at some point in time, and your application barfs on that old request, then something is broken in your application. If "dynamic pages" are really just pattern matches using path variables, then your code should be responsive to those situations, as each page request should be handled appropriately.

Example: I have a page to display a user's public profile. Maybe the user unregisters from my site. Now the "page" shouldn't "exist". In Spring, for example, I would use a PathVariable and make my handler responsive to the existence or non-existence of the user:

@RequestMapping(value="/display/{userkey}")
public String displayUser (@PathVariable("userkey") String userkey) {
    User user = someDAO.getUser(userkey);
    if(user != null) {
        // do something
    } else {
        // do something else
    }
    return "theView";
}

In this case, I would return some meaningful message to the browser, or maybe redirect to another location. This seems to be less a security issue and more one of application design.

atrain
  • 9,139
  • 1
  • 36
  • 40
  • They are resources: files like images, pdfs, etc (is a CMS). As I said, we have one controller for each "resource type". But we have so many of them that we are trying to centralize this logic in a single filter. I know that we can add a "front controller" with a "service to worker" for this, but with a filter we can add this feature without changing any module ("interception filter"). Maybe we missed something in the design, so I will start another thread to discuss this, but even with an architectural solution, I found interesting knowing how to work with the j_security_check :-D – ggarciao Aug 31 '11 at 07:49