Yes, Unfortunately, I bounced off this as well, it would have behooved the Servlet API developers to allow URL Rewrites to be a little more powerful from a REGEXP standpoint. Look at the j2sdk1.4 api, we now have regexp's available there default. One would suspect that the Servlet API could easily start allowing more complex regexp into these entries.

I would recommend writing a Filter that gets run prior to all jsp's and applying your own regexp/forwarding to the jsp's when you deem it appropriate. This requires j2sdk 1.4 and is pseudo code.


public final class BlockJspFilter implements Filter {


String regexp = "*.(/foo/bar.jsp|/bim/bam.jsp).*";

   public void doFilter(ServletRequest request,
      ServletResponse response, FilterChain chain)
      throws IOException, ServletException {

      if(request.getRequestURL().matches(regexp)){
        /*send an error response*/
      else{
        chain.doFilter(request, wrapper);
      }
      ...
   }
}

   <filter>
      <filter-name>BlockJspFilter</filter-name>
      <filter-class>BlockJspFilter</filter-class>
   </filter>
   <filter-mapping>
      <filter-name>BlockJspFilter</filter-name>
      <url-pattern>*.jsp</url-pattern>
   </filter-mapping>

One could even go as far as to use the FilterConfig to pass in the regexps which could then be dynamically adjusted in the web.xml

http://java.sun.com/products/servlet/Filters.html

-Mark Diggory


Albert Moliner wrote:
Finally I'll add the restriction on publication, but anyway it would nice to
know whether there's a solution to prevent the JSP from being served (yes,
retrieving an error message or just returning the JSP contents without executing
the class would be alright), at least for the sake of knowing.

The only problem with your alternative is that the mapping is not valid: Perhaps
Tomcat accepts it (I don't think so, as manymonths ago I tried similar mappings
and did not succeed), but anyway the servlet specs only regard four types of
mapping:
- exact path,
- directory ("/foo/bar/*"),
- extension ("*.jsp"),
- default("/").
I don't know why (performance?), but there's no place for things like
"/whatever/*.ext".

About Tim's answer, there are some things that I don't see clear, basically
dealing with the default servlet. The default servlet is after all a servlet, so
it ought to be "forwardable" (something to do with having it defined in the
general web.xml and the forwarder servlet in the app's?). Anyway, the security
constraint seems the best approach. I'll look up the security documentation.

Thank you very much (though alternatives are still welcome, as I said before).

Albert.


----- Original Message ----- From: "Ben Souther" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Friday, December 12, 2003 3:36 PM Subject: Re: Disabling JSP execution under certain dirs


It sounds like Albert wants certain (static) files to be viewable. He just doesn't want anyone to be able to execute JSPs from this directory.

One thing you could try is a servlet mapping that sends all requests ending in
that directory that end with .jsp to a servlet that sends back a message
("FORBIDDEN FILE").

  <servlet-mapping>
    <servlet-name>ForbiddenFileServlet</servlet-name>
    <url-pattern>/DIRECTORY_NAME/*.jsp</url-pattern>
  </servlet-mapping>

-Ben

On Friday 12 December 2003 09:10 am, Tim Funk wrote:

Ideally, files you don't want to be seen should be placed in WEB-INF.

An alternative is to use a security constraint on the directory that has
all of the content. This can be done in apache too via the <Location>
directive.

Another way is to place all those JSP's with a different extension and then
add the mapping to web.xml. Then add the security contraint for that file
extension. (Or let apache disallow that file extension)

Forwarding to the default servelt WILL provide a 404 because it is a 404.
The default servlet gets any request not assigned to any other servlet. So
if the default servlet find the resource, it returns a 404.

-Tim

Albert Moliner wrote:

Hello.

I've searched the archives on this subject, but the nearest I've reached
has been some posts about not serving static content. It's a bit of a
surprise that no one has asked this before, so sorry if it is a recurrent
question.

I want Tomcat (4) to execute JSPs as usual, but prevent it from running
the files that are under a certain directory for security reasons. These
files can be published by external people and are supposed to be static,
but if some mischievous publisher posts a JSP and it is executed then
there can be havoc.

Apart from preventing the publishing of files with that extension, is
there a possible configuration that can be set up?

I've tried mapping requests to that dir to the default servlet in
web.xml, but 404 errors are returned (why??), and some other wierd things
like using an intermediate servlet that forwards to the default servlet
through its named request dispatcher (the forward method does not seem to
do anything when using the dault servlet, while any other seems to work)
or setting up a separate context for that dir and forward requests to the
context, which maps *.jsp to the default context (I'll skip the details),
but I can't find the solution...

What astonishes me more is that forwarding or mapping to the default
servlet does not work, but anyway I must be doing something wrong...

--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]


--
Ben Souther
F.W. Davison & Company, Inc.



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to