Now, you can indicate what verification method used by the server. "It's great," You said, "Unless I can specify a URL that is protected, there is not much place." Yes. Point out these URLs and explains what they should protect is the purpose of the security-constriaint element. This element should appear in front of Login-Config in Web.xml. It contains a possible child element, namely Web-Resource-Collection, Auth-Constraint, User-Data-Constraint, and Display-Name. The following sections describe them.
l Web-resource-color
This element determines the resources that should be protected. All Security-Constraint elements must contain at least one Web-Resource-Collection item. This element is given a web-resource-name element that gives an arbitrary identification name, a URL-Pattern element that determines the URL that should be protected, and a HTTP command (GET, POST, etc.) that should be protected (GET, POST, etc.) HTTP-METHOD Elements and an optional Description element for providing information. For example, the following Web-Resource-Collection item (within Security-Constratint elements) indicates that all documents in the ProPrietary directory of the web application should be protected.
It is important to note that URL-Pattern is only available to clients directly accessing them. In particular, it is not suitable for using the page of RequestDispatcher through the MVC architecture, or not suitable for use with a means similar to JSP: Forward to access the page. This uniformity is very good if it is useful. For example, the servlet can use the MVC architecture to find data, put it in the bean, send requests to extract data from the bean and display it. We hope that it will never access protected JSP pages directly, but just access it by establishing this page will be used. URL-Pattern and Auth-Contraint elements can provide this guarantee by declaring any users to directly access JSP pages directly. However, this uniform behavior may allow developers to relax and make them chance to provide unrestricted access to protected resources.
l Auth-consterain
Although the URL of the web-resource-colorion element should be protected, the Auth-Constraint element indicates which users should have access to the protected resource. This element should include one or more user category Role-name elements that have access rights, and a Description element that describes (optional). For example, the Security-Constraint element department in Web.XML specifies only access to the specified resource only by specifying an Administrator or Big Kahuna (or both).
It is important to recognize that this process is over. How does the server determine which users are in any role and how it stores the user's password, which is fully dependent on a specific system.
For example, Tomcat uses install_dir / conf / Tomcat-users.xml to associate the username with the role name and password, as shown in the following example, indicating that the user Joe (Password Bigshot) and Jane (password ENAJ) belong to Administrator and Kahuna roles.
l User-data-connection
This optional element indicates any transport layer protection when accessing the relevant resources. It must contain a Transport-Guarantee sub-element (legal value is None, Integral or Confidential), and optionally contains a Description element. Transport-Guarantee will not restrict the communication protocol used for the NONE value. The IntegRal value indicates that the data must be transferred in a manner that prevents people from intercepting it. Although the principle (and in the future HTTP version), there may be differences between Integral and Confidential, but in the current practice, they just simply require SSL. For example, the following indicates that the server only allows an HTTPS connection to the relevant resource:
l Display-name
This rarely used sub-elements of Security-Constraint gives a name that may be used by the GUI tool.
