Thanks Erik, I'm going to hold off for awhile and see if anyone clarifies the public nature of the .jsp files and any possible way around it. In the meantime I'll keep experimenting on my own. If that leads to nothing, as I sort of suspect it will, then it's on to filters and more questions about them.
Ken -----Original Message----- From: Erik Price [mailto:eprice@xxxxxxx] Sent: Friday, February 21, 2003 12:40 PM To: Tomcat Users List Subject: Re: Mapping .jsp to controller servlet Januski, Ken wrote: > Erik, > > Thanks. Sorry I haven't been clearer. The servlet does use request.include. > I just added a try/catch to it and noticed that it fails when trying to > include the file that I've put in WEB-INF. The error is > "javax.servlet.ServletException: queries.jsp". Oh. Sorry about that. For some reason I remember someone on this list saying that they did something like putting their JSPs in WEB-INF and include() or forward()ed to them. But I must have been mistaken. > I would like to get a few things clear before I pursue filters, which I > haven't used before. Is it true that any jsp file put in root directory will > be accessible to anyone by just putting the url to it in browser? It is my understanding that this is how it is supposed to work. I have changed my own code to use servlets that forward to JSPs, but originally I started out with a setup that allowed users to directly request JSPs. It doesn't require any special extra effort on the part of the developer. > And if so > do you or anyone else know if moving it to a protected folder should solve > it. I know that's your theory. If it's correct then for now I'll pursue > getting that to work. If not then I guess I'll need to take a closer look at > filters. Hopefully someone else can clarify. But the theory would go like this: 1. All JSPs are tucked away in a subdirectory. 2. A filter is mapped to any requests of any resource under that subdirectory. 3. The filter checks the session to determine if the user making the request is properly authenticated. If so, do nothing (actually, doing nothing really means allowing the filter to call its "doFilterChain" method, which in this case would allow the request to pass through since the JSP itself is the next resource in the chain). However, if the user's session indicates that the user is not authenticated, you could call response.sendRedirect() to send the user to another page or servlet or perhaps the Login resource. However, be sure to put a return statement immediately after the call to "sendRedirect" because I discovered (in implementing an identical filter to the one I am describing) that the sendRedirect doesn't happen fast enough to stop the filter from calling "doFilterChain", and that the JSP would get served anyway. Putting a "return" in your filter will prevent the doFilterChain() from getting called. If this is confusing, fire away, I can explain this better in more detail. Erik --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-user-unsubscribe@xxxxxxxxxxxxxxxxxx For additional commands, e-mail: tomcat-user-help@xxxxxxxxxxxxxxxxxx --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-user-unsubscribe@xxxxxxxxxxxxxxxxxx For additional commands, e-mail: tomcat-user-help@xxxxxxxxxxxxxxxxxx
