Restrict access to web resources on JSP pages

Now, you can indicate Server The verification method used. "Amazing," you said. "unless I can specify a URL to be protected, it will be of little use ." Yes. It is the purpose of the security-constriaint element to identify these URLs and indicate what protection they should obtain. This element should appear in the web. xml before the login-config. It contains possible sub-elements: Web-resource-collection, Auth-constraint, user-data-constraint, and display-name.

The following sections describe them.
Web-resource-collection
This element determines the resources to be protected. All security-constraint elements must contain at least one web-resource-collection item. This element is composed of a Web-resource-name element that gives an arbitrary identifier name, a URL-pattern element that determines the URL to be protected, and an HTTP command that indicates the applicable protection (get, post, etc, the HTTP-method element is composed of an optional description element that provides information. For example, the following web-resource-collection item (in the security-constratint element) indicates that all documents in the proprietary directory of the Web application should be protected.
<Security-constraint>
<Web-resource-coolection>
<Web-resource-Name> proprietary </Web-resource-Name>
<URL-pattern>/propritary/* </url-pattern>
</Web-resource-coolection>
<! --... -->
</Security-constraint>
It is important to note that URL-pattern is only applicable to clients that directly access these resources. In particular, it is not suitable for pages accessed by using requestdispatcher through the MVC Architecture, or pages accessed by means similar to JSP: forward. This kind of imbalance is very beneficial if it is used properly. For example, servlet can use the MVC Architecture to search for data, put it into the bean, send a request to the JSP page that extracts data from the bean, and display it. We want to ensure that we will never directly access the protected JSP page, but access it by creating the bean servlet that the page will use. The URL-pattern and Auth-contraint elements provide this guarantee by declaring that no user is allowed to directly access the JSP page. However, such uneven behaviors may cause developers to relax their vigilance and occasionally provide unrestricted access to protected resources.
Auth-Constraint
Although the web-resource-collention element indicates which URLs should be protected, the auth-constraint element indicates which users should have access to protected resources. This element should contain one or more role-name elements that identify the user category with access permissions, and (optional) description elements that contain one descriptive role. For example, the security-constraint element department in the following web. XML requires that only administrator or big
Users of Kahuna (or both) have access to the specified resource.
<Security-constraint>
<Web-resource-coolection>... </Web-resource-coolection>
<Auth-constraint>
<Role-Name> administrator </role-Name>
<Role-Name> Kahuna </role-Name>
</Auth-constraint>
</Security-constraint>
It is important to realize that the portable part of this process has ended. Server How to determine which users are in any role and how they store their passwords depends on the specific system.
For example, Tomcat uses install_dir/CONF/tomcat-users.xml to associate the user name with the role name and password, as shown in the following example, it points out that the user Joe (password bigshot) and Jane (password enaj) belongs to the Administrator and Kahuna roles.
<Tomcat-users>
<User name = "Joe" Password = "bigshot" roles = "Administrator, Kahuna"/>
<User name = "Jane" Password = "enaj" roles = "Kahuna"/>
</Tomcat-users>
User-data-Constraint
This optional element indicates any transport layer protection when accessing related resources. It must contain a transport-guarantee sub-element (valid value: None, integral, or confidential) and optional include a description element. If transport-guarantee is set to none, the communication Protocol No restrictions apply. The integral value indicates that the data must be transmitted in a way that prevents the person who intercepts it from reading it. Although, in principle (and in future HTTP versions), there may be differences between integral and confidential, in the current practice, they simply require SSL. For example, the following indicates that the server only allows HTTPS connections to related resources:
<Security-constraint>
<! --... -->
<User-data-constraint>
<Transport-guarantee> confidential </transport-guarantee>
</User-data-constraint>
</Security-constraint>
Display-name
This rarely used sub-element of security-constraint can be used by GUI tools. Security Name of a constraint