12.4.4 The protect rules

Here we discuss everything you need to know about the protect rules, defined by the <protect> elements.

12.4.4.1 Nesting of protect rules

You can have one or more of these <protect> elements. They can be nested, in case of nesting, only the leaf <protect> elements (= those without children) define actual protect rules. The parent <protect> elements are used to define common attributes, which will be inherited by the child protect elements.

Some examples will clarify this:

Example 1
---------
<protect module="moduleA" restservice="service1" path="/foo/*" access="ROLE_USER"/>
<protect module="moduleA" restservice="service1" path="/bar/*" access="ROLE_ADMIN"/>

can be rewritten as

<protect module="moduleA" restservice="service1">
  <protect path="/foo/*" access="ROLE_USER"/>
  <protect path="/bar/*" access="ROLE_ADMIN"/>
</protect>

Example 2
---------
<protect module="moduleA" restservice="service1" path="/foo/*" access="ROLE_USER"/>
<protect module="moduleA" restservice="service1" path="/bar/*" access="ROLE_ADMIN"/>
<protect module="moduleB" restservice="service1" path="**" access="ROLE_USER,ROLE_ADMIN"/>

can be rewritten as

<protect module="moduleA">
  <protect restservice="service1">
    <protect path="/foo/*" access="ROLE_USER"/>
    <protect path="/bar/*" access="ROLE_ADMIN"/>
  </protect>
</protect>
<protect module="moduleB">
  <protect restservice="service1" path="**" access="ROLE_USER,ROLE_ADMIN"/>
</protect>

While the examples above perform grouping by the logical hierarchy module > restservice > path, you could also group them by access or any other attribute.

12.4.4.2 Order of the protect rules

The order of the protect rules is important: the first matching rule will be used.

12.4.4.3 The path and type attributes

The path attribute is an expression matching the request path, and the type attribute specifies the type of expression.

The type can be:

• ant (the default): the expression can contain the wildcards * (= matches one path segment) and ** (= matches multiple path segments)
• regex: for regular expressions
• template: for URI template expressions

The path that should be matched is the path handled by the particular REST-service, thus already stripped from the prefix on which the REST-service is mounted in the wiring.xml. The query string is not part of the path either. The path is decoded, so all escaped sequences (%HH) will be replaced by the actual characters.

12.4.4.4 The method attribute

Can contain an HTTP method name such as GET, PUT, POST or DELETE. The rule will only apply for a request if the method of the request is the same as the value of this method attribute.

12.4.4.5 The access attribute

The access attribute is a comma separated list of values. These values are typically role names, but for completeness we should mention that in Spring Security these are called configuration attributes, and they might represent other things.

For advanced usage: the configuration attributes don't need to be strings, though this configuration only allows for string-based configuration attributes. In case you want something else than strings, you can use a custom ObjectDefinitionSource using the <objectDefinitionSource> element.