This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
Perhaps someone here can give me a hand with this because I'm afraid I've run into a bit of a wall on this one.
I'm working on a web application which uses multiple JSP pages. However, in order for these pages to work properly the user must first come through a single "setup" screen in which they select the site they would like to administer. Without first selecting a site, the other pages won't be able to function.
So, my ideal goal would be to redirect the user back to that "setup" screen any time they try accessing another one of the pages. I thought a Filter would be a perfect way to set this up because I could simply map that filter to the URL patterns for my various JSP pages and I could write the code to check for a selected site and redirect the user in one place. Unfortunately, despite my plan, things aren't going so smoothly.
First, I wrote a very simple filter that looked like this (this was within the doFilter method):
That code is pretty simple. It just checks for a value in the session and, if it isn't there, it redirects the user back to the home page for the application. Unfortunately, it doesn't work. If I try to execute this, I get an error like this:
I'm not quite certain what's happening here. I was hoping that I could capture the request and re-route it before it ever reached the JSP the user had requested. Instead, I get an error as if there are two places where a response is being created.
I tried putting the redirect after the "chain.doFilter(req, resp);" and that only led to another error message. I've been reading through "Head First Servlets and JSP" about creating custom Request and Response objects but, in all honesty, I'd read less confusing things in the past.
Anyone out there able to shed a bit of enlightenment on what's going on here and give me some direction. If I could more clearly understand what was going on, I could probably make more headway.
That is odd. As far as I can tell, there's nothing wrong with your reasoning. I use this pattern all the time to make sure that users are logged in before letting them into the site. The one difference is that the URLs never directly reference a JSP (I always go through a servlet controller), but that shouldn't make any difference. The filter should be invoked before anything gets a chance to write to the response.
Are there other filters that could be gumming up the works?
Originally posted by Bear Bibeault: I use this pattern all the time to make sure that users are logged in before letting them into the site. The one difference is that the URLs never directly reference a JSP (I always go through a servlet controller)...Are there other filters that could be gumming up the works?
Well, this is very related. There is one other filter being used, written by someone on a different team. That filter is used to authenticate the user and pull various bits of information about the user so that we can use it in our application without having to write the code to do so ourselves.
The problem with that filter is that it simply sends the user on to whatever page they requested in the first place. So, if the user requested some "internal" page, rather than the normal main page, they'd be able to get there after authentication, even if the user hadn't yet selected a site.
My approach was to put my filter on all of the pages/struts actions in my application. If a site wasn't selected, the user would be sent to the index page, which has the authentication filter on it. If the user was not yet authenticated, they'd be asked to do so and then forwarded on to the entry page. If the user had already authenticated, they'd simply go on to the entry page without authenticating, but I doubt that would ever be the case.
Realistically, I don't know why a user would ever try to access an "inner" page without first going through the entry page but, nonetheless, I'd like to prevent them from doing so in the case that they would try. If they could, I'm almost certain they could find a way to do something evil. :roll:
I don't believe the other filter is "in the way" as I'm not being sent to the authentication page and that's what that filter is designed to do. I'm just thoroughly confused on this one.