The <security-constriant> element is used by tomcat to instruct the server to impose security constraints on client access to server resources. If the verification fails, a 403 error will be reported
<security-constraint>
<web-resource-collection>
<web-resource-name>test</web-resource-name>
<url-pattern>/index.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>pluto</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>·
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/login.jsp?error=1</form-error-page>
</form-login-config>
</login-config>
<security-role>
<role-name>pluto</role-name>
</security-role>
<security-constriant> contains 4 possible sub-elements: web-resource-collection, auth-constraint, user-data-constraint and display-name.
1.web-resource-collection This element determines the resources to be protected, and all security-constraint elements must contain at least one of this. Below this element is a <web-resource-name> giving an arbitrary identifying name, a url-pattern element identifying the URL to be protected, an http- The method element consists of an optional description element that provides information. In the above example, it will be restricted when you access "/index.jsp" with GET, POST, PUT methods. We usually default to GET method access. If you comment out the line <http-method>GET</http-method>, no error will be reported.
2. The auth-constraint element indicates which users should have access to protected resources. This element should contain one or more role-name elements identifying the user with access rights, and an optional description element. If there is no auth-constraint sub-element in security-constraint, users of any identity can access the corresponding resources, which means that security-constraint does not actually work at this time. This element needs to be used in conjunction with <login-config>, <login-config> should follow the security-constraint
3.user-data-constraint This optional element indicates the transport layer protection used when accessing the associated resource
There are four authentication types for <login-conifg>
BASIC: HTTP specification, Base64
DIGEST: HTTP specification, stronger data integrity, but not SSL
CLIENT-CERT: J2EE specification, strong data integrity, public key (PKC)
FORM: J2EE specification, data integrity is very weak, no encryption, allows a customized login interface
As in the above example, the login interface is login.jsp. The FORM method here needs to be explained that the fixed elements of the login interface
<form name="loginform" method="post" action="j_security_check"> <INPUT name="j_username" type="text"> <INPUT name="j_password" TYPE="password"> <input type="submit" value="登 录" > </form>
The action of the form must be "j_security_check", method="post", username name="j_username", password name="j_password" These are all fixed elements.
Then what should the username and password be filled in here? There is a tomcat-users.xml file in the conf directory of tomcat, in which you can add a line <user name="mao" password="mao" roles="tomcat,pluto"/>, which means users of tomcat and pluto roles The name and password are both "mao".
Now visit the "/index.jsp" interface, jump to login.jsp, fill in the username and password "mao", and then you can access the content of index.jsp
Another important point is that security-constraint only works for external access, and does not work for internal jumps.
For example, when accessing a servlet, if the method is response.sendRedirect("/xiangmuming/index.jsp"), a 403 error will still be reported. If it is request.getRequestDispatcher("/index.jsp").forword(request,response ) can be accessed by jumping
request.getRequestDispatcher().forward(), is a server jump, the address bar address remains unchanged, the old request and response are all passed to the page
request.sendRedirect(), belongs to the page jump, which is equivalent to two visits, the address changes, the request and the response are all new, that is, the visit is twice