4 Replies Latest reply on Oct 18, 2005 1:13 PM by treespace

    WAR security failure

      I want to block all access to files with a specific extension. I tried using a security constraint with a non-existent role but that did not prevent acess to files with the extension "vax".

      It is impractical to move these files to a WEB-INF folder so they are out in the open for the time being. Do I need to create this role? Do users have to be mapped to the role and if so where is that done. The MemoryRealm with tomcat-users.xml did not work.

       <security-constraint>
       <web-resource-collection>
       <web-resource-name>mask</web-resource-name>
       <url-pattern>*.vax</url-pattern>
       <auth-constraint>
       <role-name>void</role-name>
       </auth-constraint>
       </web-resource-collection>
       </security-constraint>
      
       <security-role>
       <role-name>void</role-name>
       </security-role>
      


        • 1. Re: WAR security failure

          P.S. We use form-based login without JAAS and would not like to add a login module if possible. We just want certain extensions to be inaccessible via direct HTTP request.

          • 2. Re: WAR security failure

            I know this doesn't address the problem you're having WRT security, but perhaps there's another way to achieve what you want.

            You could write a very simple servlet whose service method simply sends a 404 back to the response. Then map *.vax to that servlet. This will make it look like those files don't exist via a direct HTTP request.

            Using a security constraint, the response would be something like a 401 or 403. It could also cause the browser to be redirected to your login page.

            • 3. Re: WAR security failure
              brian.stansberry

              From the Servlet 2.4 spec, section SRV.12.8:

              An authorization constraint that
              names no roles indicates that access to the constrained requests must not be
              permitted under any circumstances.


              So, an empty authorization constraint element should get you what you want.

              I must admit I'm not certain why your "fake role" didn't work, but in any case the authorization constraint with no roles is the standard way to do it.

              • 4. Re: WAR security failure

                Thanks for replies. Turns out I cannot eliminate every URL access to those resources so I will have to use a bona fide role. Since we use our own home brewed authentication/authorization, a servlet filter should do the trick.