Name
<security-constraint>
Synopsis
The <security-constraint>
element contains a <web-resource-collection>
subelement that defines the resources to be protected and an
<auth-constraint>
subelement that defines
who has access to the protected resources. It can also contain a
<user-data-constraint>
subelement that
describes security requirements for the connection used to access the
resource:
<security-constraint> <web-resource-collection> <web-resource-name>admin</web-resource-name> <url-pattern>/admin/*</url-pattern> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</ transport-guarantee> </user-data-constraint> </security-constraint>
Within the <web-resource-collection>
element, the resource is given a name with the
<web-resource-name>
subelement, and the URI
patterns for the protected resources are specified with
<url-pattern>
elements.
<http-method>
sub-elements can also restrict
the types of accepted requests. This example protects all resources
accessed with URIs that start with /admin
and says
that only the GET
method can access these
resources.
The <role-name>
subelements within the
<auth-constraint>
element specify the roles
the current user must have to get access to the resource. The value
should be a role name defined by a
<security-role>
element, but some containers
(such as Tomcat) accept role names that aren’t
defined by <security-role> ...
Get JavaServer Pages, Second Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.