Tomcat configuration tips Top 10 (2)

4. Configure Virtual Hosts)

The "Host" element in server. xml must be modified only when you set the virtual Host. A vm is a mechanism that serves multiple domain names on a web server. For each domain name, it seems that the entire host is exclusive. In fact, most small business websites use virtual hosts. This is mainly because virtual hosts can directly connect to the Internet and provide corresponding bandwidth to ensure reasonable access response speed, in addition, the VM can provide a stable fixed IP address.

A name-based virtual host can be created on any web server by creating an IP address alias on the Domain Name Server (DNS, the web server is also notified to distribute requests to different domain names to the corresponding web directory. This article is mainly about Tomcat. We are not going to introduce how to set up DNS on various operating systems. If you need help in this regard, please refer to the book DNS and Bind, the author is Paul Albitz and Cricket Liu (O 'Reilly ). For ease of demonstration, I will use a static host file because this is the easiest way to test aliases.

To use a VM in Tomcat, you need to set DNS or host data. To test, it is enough to set an IP alias for the local IP address. Next, you need to add several lines of content in server. xml, as shown below:

<Server port="8005" shutdown="SHUTDOWN" debug="0"> <Service name="Tomcat-Standalone"> <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="8080" minProcessors="5" maxProcessors="75" enableLookups="true" redirectPort="8443"/> <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="8443" minProcessors="5" maxProcessors="75" acceptCount="10" debug="0" scheme="https" secure="true"/> <Factory className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory" clientAuth="false" protocol="TLS" /> </Connector> <Engine name="Standalone" defaultHost="localhost" debug="0"> <!-- This Host is the default Host --> <Host name="localhost" debug="0" appBase="webapps" unpackWARs="true" autoDeploy="true"> <Context path="" docBase="ROOT" debug="0"/> <Context path="/orders" docBase="/home/ian/orders" debug="0" reloadable="true" crossContext="true"> </Context> </Host> <!-- This Host is the first "Virtual Host": http://www.example.com/ --> <Host name="www.example.com" appBase="/home/example/webapp"> <Context path="" docBase="."/> </Host> </Engine> </Service> </Server>

Tomcat's server. xml file contains only one virtual host in the initial state, but it is easy to expand to support multiple virtual hosts. The preceding example shows a simple server. xml version. The bold part is used to add a VM. Each Host element must contain one or more context elements. The contained context element must have a default context. The display path of this default context should be blank (for example, path = "").

5. Configure Basic Authentication)

The container management authentication method controls how users perform identity authentication when they access protected web application resources. When a web application uses Basic Authentication (the BASIC parameter is stored on the web. when a user accesses a protected web application, Tomcat will pop up a dialog box through HTTP Basic Authentication, enter the user name and password. In this authentication method, all passwords are transmitted over the network in 64-bit encoding mode.

Note: using Basic Authentication is considered insecure because it does not have robust encryption methods, unless you use HTTPS or other password and password methods on both the client and server (for example, in a virtual private network ). Without any additional encryption method, the network administrator can intercept (or misuse) the user's password. However, if you are using Tomcat or want to test container-based security management in your web application, Basic Authentication is very easy to set and use. You only need to add And Two elements go to your web application's web. xml file and add the appropriate And Then restart tomcat.

The web. xml in the following example is taken from a club member website system. In this system, only the member directory is protected and Basic Authentication is used for identity Authentication. Note that this method will effectively replace the. htaccess file on the Apache web server.

<!-- Define the Members-only area, by defining a "Security Constraint" on this Application, and mapping it to the subdirectory (URL) that we want to restrict. --> <security-constraint> <web-resource-collection> <web-resource-name> Entire Application </web-resource-name> <url-pattern>/members/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>member</role-name> </auth-constraint> </security-constraint> <!-- Define the Login Configuration for this Application --> <login-config> <auth-method>BASIC</auth-method> <realm-name>My Club Members-only Area</realm-name> </login-config>

6. Configure Single Sign-on)

Once you have set the realm and authentication methods, you need to perform the actual user logon process. Generally, it is very troublesome for users to log on to the system. You must minimize the number of user login verification times. By default, when a user requests a protected resource for the first time, each web application requires the user to log on. If you run multiple web applications and each application requires separate user authentication, it looks a bit like you are fighting with your users. Users don't know how to integrate multiple separated applications into a single system, and they don't know how many different applications they need to access, why do you always log on without stopping.

The single sign-on Feature of Tomcat 4 allows users to log on only once to access all web applications on the same virtual host. To use this function, you only need to add a SingleSignOn Valve element to the Host, as shown below:

<Valve className="org.apache.catalina.authenticator.SingleSignOn" debug="0"/>

After the initial installation of Tomcat, the comments of server. xml include examples of SingleSignOn Valve configuration. You only need to remove the comments to use them. Therefore, any user who has logged on to an application is equally valid for all applications on the same virtual host.

Using single sign-on valve has some important restrictions:
1> value must be configured and nested in the same Host element, and all web applications that require spof (must be defined by the context element) are located under this Host.
2> realm, which includes shared user information, must be set in the same level of Host or nested.
3> cannot be overwritten by realm in context.
4> for web applications that use single sign-on, it is best to use a built-in Tomcat verification method (defined on the web. in xml), which is better than the custom authentication method. Tomcat's built-in authentication methods include basic, digest, form, and client-cert.
5> if you use single sign-on, you also want to integrate a third-party web application to your website, and the new web application uses its own authentication method, without the use of Container Management Security, you are basically no choice. Each time your user logs on to all the original applications, You need to log on again when requesting a new third-party application. Of course, if you have the source code of this third-party web application, and you are a programmer, you can modify it, but it may not be easy to do.
6> cookies are required for single-point logon.

<Previous Page 1 2 3 next page>