9.2 Limiting access to Web resources
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.
9.3 Distribution Role Name
To date, discussions have been concentrated above the security issues that are completely processed by the container (server). But the servlet and the JSP page can also handle their own security issues.
For example, the container may allow users to access a page that displays an additional close to the executive person from a BigWig or Bigchese role, but only the BigWig user is allowed to modify the parameters of this page. One common way to accomplish this more detailed control is to call the HTTPServletRequset's ISUSERINROLE method and modify the access.
Servlet's security-role-ref child elements provide an alias that appears in the server's dedicated password file. For example, if a servlet called Request.isuserinRole ("Boss") is written, then the servlet is used in a server that calls role Manager Manager instead of BOSS. The following block allows the servlet to use any of these two names.
You can also use the Security-Role element in the web-app to provide a global list of all security roles that will appear in the Role-Name element. The life role makes advanced IDE easy to handle security information.
10 Control session timeout
If a session is not accessed at a certain period of time, the server can throw it away to save memory. You can use the HTTPSession's SetMaxInactiveInterval method to set the timeout value of individual session objects. If this method is not used, the default timeout value is determined by the specific server. However, the session-config and session-timeout elements can be utilized to give a clear timeout value for all servers. The unit of timeout is minute, so the following example sets the default session timeout value of three hours (180 minutes).
11 Web application documentation
More and more development environments begin to provide direct support for Servlet and JSP. Examples include Borland JBuilder Enterprise Edition, Macromedia Ultradev, Allaire Jrun Studio (Write this article, has been acquired by Macromedia) and IBM Visuaage for Java.
A large number of web.xml elements are not only designed for servers, but also designed to develop environment. They include Icon, Display-Name, and Discription.
Memories can be recalled in Web.xml to declare the web-app child element in the appropriate order. However, just remember that Icon, Display-Name and Description are the first three legal elements within the web-app elements of web.xml.
l icon
The ICON element indicates that the GUI tool can be used to represent one and two image files of the web application. A 16 x 16 GIF or JPEG image can be specified using the Small-ICON element, specifying an image of 32 x 32 with the Large-ICON element. Let's take an example:
l Display-name
The Display-Name element provides a GUI tool that may be used to mark a name for this web application. Here is an example.
l Description
The Description element provides explanatory text as follows:
THIS Web Application Represents The Store Developed for
Rare-books.com, An Online Bookstore Specializing In Rare
AND limited-edition books.
12 related files and MIME types
The server typically has a method that allows Web site administrators to associate file extensions to media. For example, an image / jpeg MIME type named Mom.jpg will be automatically given. However, if your web app has several unusual files, you want to ensure that they are assigned to a MIME type when sending to the client. MIME-MAPPING Elements (with Extension and MIME-TYPE sub-elements) provide this guarantee. For example, the following code indicates that the server assigns the MIME type of Application / X-FuBar to all files ending with .foo.
Perhaps your web application wants the Override standard mapping. For example, the following code will tell the server to specify the .ps file as plain text when sending to the client as a plain text rather than the PostScript (Application / PostScript).
13 positioning TLD
The JSP taglib element has a necessary URI property that gives a TLD (Tag Library Descriptor) file relative to the root of the web application. The actual name of the TLD file may change when publishing a new label library version, but we want to avoid changing all existing JSP pages. In addition, it is possible to also want to use a short URI that keeps a Taglib element. This is the Taglib element distribution field for deploying the descriptor file. Taglib contains two sub-elements: taglib-uri and taglib-location. Taglib-URI elements should match something for the URI attribute used for JSP taglib elements. The Taglib-Location element gives the actual location of the TLD file. For example, if you put the file chart-tags-1.3beta.tld in WebApp / Web-INF / TLDS. Now, if Web.xml contains the following contents within a web-app element.
/Web-inf/tlds/Chart-tags-1.3beta.tld
After this instructions are given, the JSP page can be used using the label library by the simplified form below.
<% @ Taglib Uri = "/ Charts.TLD" prefix = "someprefix"%>
14 Specify Application Event Listening Programs
Applying event listener programs are classes that are notified when establishing or modifying a Servlet environment or session object. They are new content in version 2.3 of the Servlet specification. Here is only the usage of web.xml to register a listener to the web app to the web application. Registering a listener involves placing a Listener element within the web-app element of Web.xml. Within the Listener element, the Listener-Class element lists the complete qualified class name of the listener, as shown below:
Although the structure of the Listener element is simple, please do not forget that the order of sub-elements within the web-app element must be correctly given. Listener elements are located before all Servlet elements and all filter-mapping elements. In addition, because the application life listener is a version 2.3 version of the Server Victor Victor, you must use the version 2.3 version of Web.xml DTD, not 2.2.
For example, program list 5-20 gives a simple listener called ContextRext, as long as the servlet-context of the web application (such as load web application) or elimination (such as server is turned off), it displays a standard output news. Program List 5-21 gives a part of the web.xml file required for this listener registration.
Program List 5-20 ContextReva
Package morvelvlets;
Import javax.servlet. *;
Import java.util. *;
/ ** Simple Listener That Prints a Report on The Standard Output
* When the servletcontext is created or destroyed.
*
* Taken from More Servlets and JavaServer Pages
* Frompentice Hall and Sun Microsystems Press,
*
http://www.moreservlets.com/.
* © 2002 Marty Hall; May Be Freely Used OR Adapted.
* /
Public class contextRextRements servletcontextListener {
Public void contextinitialized (servletContextevent Event) {
System.out.println ("Context CREATED ON"
New Date () ".");
}
Public void contextdestroyed (servletContext Event) {
System.out.println ("Context Destroyed ON"
New Date () ".");
}
}
Program List 5-21 Web.xml (declare an excerpt of a listener)
Public "- // Sun microsystems, Inc.//dtd Web Application 2.3 // en"
"http://java.sun.com/dtd/web-app_2_3.dtd">
15 J2EE element
This section describes the web.xml element for web applications for the J2EE environment components. Here will provide a concise introduction, please refer to Http://java.sun.com/j2ee/j2ee-1_3-fr-spec.pdf's Java 2 Plantform Enterprise Edition version 1.3 specification chapter 5.
l Distributable
The Distributable element indicates that the web application is programmed in such a way: that is, the server that supports the cluster can be securely distributed on multiple servers on multiple servers. For example, a distributable application must only use the Serializable object as the properties of its HttpSession object, and must avoid continuity with instance variables (fields). The Distributable element directly appears after the discrtion element and does not contain sub-elements or data, which is just a marker.
l resource-env-ref
Resource-Env-Ref element declares a management object related to a resource. This element is made of an optional Description element, a resource-env-ref-name element (a JNDI name relative to the Java: Comp / ENV environment) and a resource-env-type element (fully qualified class specified by the resource type ),As follows:
JMS / stockQueue
Javax.jms.Queue
l Env-entry
Env-entry elements declare the environment item for web applications. It is made by an optional Description element, an env-entry-name element (a java: comp / ENV environment JNDI name), an env-entry-value element (item value) and an env-entry-type element ( A fully qualified class name, java.lang.boolean, java.lang.string, etc. in the java.lang package. Below is an example:
l EJB-REF
The EJB-REF element declares the application of the primary directory of an EJB. It is made from an optional Description element, an EJB-REF-NAME element (AppAeted relative to Java: Comp / ENV EJB), an EJB-Ref-Type element (Type of beans, entity or session), an Home element ( The fully qualified name of the main directory interface of the bean), a Remote element (a fully qualified name of the Remote interface of the bean) and an optional EJB-LINK element (the name of another bean of the current bean link) consists of. l ejb-local-ref
EJB-local-ref elements declare an EJB's local host directory reference. This element has the same attribute as the EJB-REF element in addition to local-home, which is used in the same manner.
