The first problem I ran into was that certain urls will not hit the filter, while others will. I read online and in these forums and found that it could be because I'm using a dispatch.forward(), whereas the filter looks for requests by default. So I added in the two dispatcher tags to web.xml to specify both the forward and the request. But now when I try to access my web-app I get the following exception on my filter chain:
Does anyone know what I'm doing wrong, or am I wrong in my assumption that I need to adjust the dispatcher in web.xml to ensure the filter snags the missing forwards?
What are you doing in your filter?
Are you forwarding to something?
If so, is it possible that you've set up an endless loop by catching the forward with a filter that tries to forward which gets caught again by the filter which tries to forward which gets caught by the filter which tries to forward to something that gets caught by the filter......?
If it's not too long, post the code to your filter.
Chad Cook wrote:Good catch. Is there a way to configure the forward so that it will not catch index.jsp, but everything else? Is this the proper way to attack this?
Not unless you have your index.jsp in a separate directory.
If it were me, I'd take a good look at why I need this filter to catch forwards.
Is there anything else you could map to in your URLs other than *.jsp?
Situations like this are a good example of why Front Controllers make sense.
Eddy Pelaic wrote:...
I don't think there is enough information in this thread for us to make suggestions such as this (which is why I didn't make any concrete suggestions).
If there is an image in the NeoAdmin directory that gets used in the index.jsp page the filter would catch it and try to redirect it to the index.jsp with the URL pattern you've suggested.
The original poster needs to take a long look at how he's got his app structured and figure out whether there even is a url-pattern or group of them that would work. If not, he needs to consider restructuring the application so that this can be done.
It's right, there is not enough informations, but if the index.jsp is in public "area", it should not use images or resources in secure directories. I consider that's all resources must be in a "resources" folder in public access, and specials critical resources in a subdirectory of secured directory or provided by secure code (filter/servlet/Jsp).
It's better to have a clean separation of public / secure.
The url pattern "*.jsp" works only for JSP's, but not for others extension or servlet's url "/myservlet.1234". So it's more difficult to ensure secure access for all resources with that url-pattern.
In the filter, he can check if the browser want to GET an picture and return a 404 code than forwarding to index page. But it's more complex to do and time consuming of CPU.
I did that for Flex UI HTTP/XML and Ajax request to not have the login page content in the response, because the forward send a 200 status code and it's simpler to handle status code than check the content of page.
Eddy Pelaic wrote:... I consider that's all resources must be in a "resources" folder in public access, and specials critical resources in a subdirectory of secured directory or provided by secure code (filter/servlet/Jsp).
Another assumption that I wouldn't be prepared to make.
Again, if this were my project, I would take a good look at how things are organized and then determine whether there is a url-pattern (or group of them) that will work OR whether I need to restructure the app (possibly adding a front controller) to make it possible to do this cleanly.
this problem could be a good question for SCWCD exam, Chad now knows why he get a StackOverflowException => infinite recursion and and how to fix it => web app structure / url-pattern.
I assumed with "*.jsp" url-pattern, that Chad's application is a "direct access to JSP's" based web app. For the Front controller pattern it's another topic, why only use Servlet's and Jsp's ?