Use Web.xml to control the behavior of Web applications (restricting access to Web resources) __web

restricting access to Web resources

You can now indicate what authentication method the server is using. "Great," you said, "It's not very useful unless I can specify a URL to receive protection." Yes The purpose of the Security-constriaint element is to point out these URLs and explain what protection they should get. This element should appear in front of the login-config in the Web.xml. It contains a possible child element, namely Web-resource-collection, Auth-constraint, User-data-constraint, and Display-name. They are described in the following subsections.

web-resource-collection

This element determines which resources should be protected. All security-constraint elements must contain at least one web-resource-collection item. This element consists of a web-resource-name element that gives any identifying name, a Url-pattern element that determines the URL that should be protected, and an HTTP command (GET, post, and so on) that is applicable to this protection. The Http-method element of the default is all methods) and an optional description element that provides the data. For example, the following Web-resource-collection entry (within the Security-constratint element) indicates that all documents in the proprietary directory of the Web application should be protected.

Proprietary
/propritary/*

!--...--

It is important to note that Url-pattern only applies to clients that directly access these resources. In particular, it is not suitable for pages accessed through the MVC architecture using RequestDispatcher, or pages that are not accessible using a similar jsp:forward approach. This kind of symmetry is good if used properly. For example, a servlet can use the MVC architecture to find data, place it in a bean, send a request to a JSP page that extracts data from the bean, and display it. We want to ensure that the protected JSP page is never accessed directly, but only through the servlet of the bean that the page will use. The Url-pattern and Auth-contraint elements provide this assurance by declaring that no user is allowed direct access to the JSP page. However, this asymmetrical behavior may allow developers to relax their vigilance and allow them to accidentally provide unrestricted access to protected resources.

Auth-constraint

Although the Web-resource-collention meta quality has a URL that 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 class that has access rights, and a description element that contains (optionally) a description role. For example, the Security-constraint element department in the following Web.xml stipulates that only users designated as Administrator or Big Kahuna (or both) have access to the specified resource.
...

Administrator
Kahuna

It is important to realize that this is the end of the portable part of the process. How the server determines which users are in any role and how it holds the user's password depends entirely on the specific system.

For example, Tomcat uses install_dir/conf/ Tomcat-users.xml the user name with the role name and password, as shown in the following example, it states that user Joe (password Bigshot) and Jane (password Enaj) belong to the administrator and Kahuna roles.

User-data-constraint

This optional element indicates that any transport-layer protection is used when accessing related resources. It must contain a transport-guarantee child element (the legal value is none, integral, or confidential) and optionally contains a description element. Transport-guarantee to the None value will not limit the communication protocol used. The integral value means 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 current practice they simply require SSL. For example, the following indicates that the server only allows HTTPS connections to related resources:
!--...--

Confidential

Display-name

This rarely used child element of Security-constraint gives a name to a security constraint item that might be used by the GUI tool.

Assigning role names

So far, the discussion has focused on the security issues that are handled entirely by the container (server). But the servlet and JSP pages can also handle their own security issues.

For example, a container might allow a user to access a page that displays an extra close to the supervisor from the bigwig or Bigcheese role, but only allow bigwig users to modify the parameters of this page. A common way to accomplish this finer control is to invoke the Httpservletrequset IsUserInRole method and modify the access accordingly.

The Security-role-ref child element of the servlet provides an alias for the security role name that appears in the server's private password file. For example, if you write a servlet that calls Request.isuserinrole ("Boss"), the servlet is later used in a server whose password file calls the Role Manager instead of the boss. The following program segment enables the servlet to use either of these two names.
!--...--

boss !--New alias-->
Manager !--real name-->

You can also use the Security-role element within Web-app to provide a global list of all the security roles that will appear in the Role-name element. Separate life roles enable the Advanced IDE to handle security information easily.

Controlling Session Timeout

If a session is not accessed within a certain amount of time, the server can throw it away to save memory. You can set the timeout value of an individual Session object directly using the HttpSession Setmaxinactiveinterval method. If this method is not used, the default timeout value is determined by the specific server. However, you can use the Session-config and session-timeout elements to give a clear time-out value that applies to all servers. The timeout value is in minutes, so the following example sets a timeout of three hours (180 minutes) for the missing capital.
180