url-pattern and wildcards

Question

While configuring the security constraints for a web-module's roles in J2EE application I'm having the following problem:

Application:

Giving a servlet named customersServlet, which receives two parameters in the URL:

• A string representing an operation (INS, UPD, DLT and DSP).
• An identification number to identify a customer on which the operation will be performed.

E.G.: the url /servlet/cusotmersServlet?UPD,5 is used to update customer number 5 data, and the usl /servlet/customersServlet?DLT,8 is used to delete customer number 8.

Problem:

If I use this security-constraint the servlet can only be accessed by the role specified, which is ok:

<security-constraint>
    <web-resource-collection>
        <web-resource-name>...</web-resource-name>
        <url-pattern>/servlet/clientsServlet*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>clientAdmin</role-name>
    </auth-constraint>
</security-constraint>

But I want to restrict the ability to insert customers only to a role named clientAdmin.

I've tried several url patterns but none of them works as I want (all of them allow every role to access the servlet with any parameter):

<url-pattern>/servlet/clientsServlet?INS,*</url-pattern>
<url-pattern>/servlet/clientsServlet?INS/*</url-pattern>
...

How to use the wildcard * in the url-pattern tag?

Note: The application cannot be changed, so I need a solution that only implies touching the deployment descriptor.

Answer 1

The <url-pattern> tag only allows a very restricted subset of wildcards. This is probably not what you are used to from other situations, where a * can be used at any position. You can download the Servlet specification here:

http://jcp.org/aboutJava/communityprocess/mrel/jsr154/index2.html

Section SRV.11.2 of that document describes how these URL patterns are interpreted. In particular, the * does not mean "zero or more arbitrary characters" here.

Answer 2

Note: The application cannot be changed, so I need a solution that only implies touching the deployment descriptor.

Not sure if this counts as an application change - perhaps you could think of it as a plug-in. You could add a Filter. This would require the ability to add a new JAR to WEB-INF/libs and the ability to define the filter in web.xml. The Filter would allow you to restrict access programmatically.