The trick you need to do is to configure Tomcat as you want, and as long as you configure it correctly, Tomcat can generally suit your needs. Here's a series of techniques for configuring Tomcat, which comes from my book: The Tomcat Authority Guide, which I hope will help you. Jason Brittain
1. Configure System Management (Admin WEB application)
Most commercial Java EE servers provide a powerful management interface, and most of them use an Easy-to-understand Web application interface. Tomcat, in its own way, also provides a sophisticated management tool that is no less competitive than those of a commercial competitor. Tomcat's admin Web application originally appeared in version 4.1, with functions such as admin context, data source, user, and group. Of course can also manage like initialization parameters, user, group, role of a variety of database management. In subsequent releases, these features will be greatly expanded, but the existing functionality is already very useful.
The Admin WEB application is defined in the automatic deployment file: Catalina_base/webapps/admin.xml.
(Translator Note: Catalina_base is the server directory under the Tomcat installation directory)
You must edit this file to determine that the Docbase parameter in the context is an absolute path. In other words, the catalina_base/webapps/admin.xml path is an absolute path. As an alternative, you can also delete the automatic deployment file, and in the Server.xml file to create a admin Web application context, the effect is the same. You can't manage the admin Web application This application, in other words, you may not be able to do anything other than delete Catalina_base/webapps/admin.xml.
If you use Userdatabaserealm (default), you will need to add a user and a role to the Catalina_base/conf/tomcat-users.xml file. You edit this file, add a role called "admin" to the file, as follows:
<role name= "Admin"/>
You also need to have a user, and the user's role is "admin". Add a user (change the password to make it more secure), as in the case of existing users:
<user name= "admin" password= "Deep_dark_secret" roles= "admin"/>
When you have completed these steps, please restart Tomcat, visit Http://localhost:8080/admin, and you will see a login interface. The Admin WEB application uses a container-managed security mechanism and employs the Jakarta struts framework. Once you are logged in as the Admin user Login Admin interface, you will be able to configure Tomcat using this admin interface.
2. Configure Application Management (Manager Web application)
The Manager Web application lets you perform some simple Web application tasks through a simpler user interface than the admin Web application.
The Manager WEB application is defined in an automated deployment file:
Catalina_base/webapps/manager.xml.
You must edit this file to ensure that the Docbase parameter of the context is an absolute path, that is, the absolute path of the Catalina_home/server/webapps/manager.
(Translator Note: Catalina_home is the Tomcat installation directory)
If you are using Userdatabaserealm, then you need to add a role and a user to the Catalina_base/conf/tomcat-users.xml file. Next, edit the file and add a role named "Manager" to the file:
<role name= "Manager" >
You also need to have a user who has the role of "manager". Add a new user (change password to make it more secure), as already existing users:
<user name= "manager" password= "Deep_dark_secret" roles= "Manager"/>
Then restart Tomcat, visit http://localhost/manager/list, see a very simple text-management interface, or visit http://localhost/manager/html/list, You will see a HMTL management interface. Either way, it means your manager Web application is now started.
Manager application allows you to install new Web applications for testing without system administration privileges. If we have a new Web application under/home/user/hello and want to install it under/hello, in order to test this application, we can do this, in the first file box, enter "/hello" (as Path to visit), and in the second text box, type " File:/home/user/hello "(as config URL).
Manager application also allows you to stop, reboot, remove, and redeploy a Web application. Stop an application so it can't be accessed, and when a user tries to access this stopped application, you see a 503 error??? 503-this application is not currently available ".
Removing a Web application means that the application is removed from Tomcat's running copy, and if you restart Tomcat, the deleted application will reappear (that is, removal is not meant to be removed from the hard drive).
3. Deploying a Web Application
There are two ways to deploy Web services in your system.
1> Copy your war file or your Web application folder (including all the content of the Web) to the $catalina_base/webapps directory.
2> creates an XML fragment file that includes only the context content for your Web service and places the file in the $catalina_base/webapps directory. The Web application itself can be stored anywhere on the hard disk.
If you have a war file, if you want to deploy it, simply copy the file to the Catalina_base/webapps directory, and the file must be extended with ". War". Once Tomcat hears this file, it unlocks the package (by default) as a subdirectory and takes the name of the war file as the subdirectory. Next, Tomcat creates a context in memory as if you were building it in a server.xml file. Of course, other necessary content will be obtained from the Defaultcontext in Server.xml.
Another way to deploy a Web application is to write a context XML fragment file and then copy the file to the Catalina_base/webapps directory. A context fragment is not a complete XML file, but a context element, as well as a corresponding description of the application. This fragment file is like a context element that is cut from the server.xml, so this fragment is named "Context fragment."
For example, if we want to deploy an application called Mywebapp.war, the application uses realm as an access control, we can use the following fragment:
!--
Context fragment for deploying Mywebapp.war
-->
<context path= "/demo" docbase= "Webapps/mywebapp.war"
debug= "0" privileged= "true" >
<realm classname= "Org.apache.catalina.realm.UserDatabaseRealm"
Resourcename= "Userdatabase"/>
</Context>
Name the fragment "Mywebapp.xml" and copy it to the Catalina_base/webapps directory.
This context fragment provides a convenient way to deploy Web applications, you do not need to edit server.xml, unless you want to change the default deployment features, you do not need to restart Tomcat to install a new Web application.
4. Configure virtual Hosts
About the "host" element in Server.xml, only if you set up a virtual host, you need to modify it. A virtual host is a mechanism that serves multiple domain names on a Web server, and for each domain name it seems to have exclusive access to the entire host. In fact, most small business Web sites are implemented using a virtual host, mainly because the virtual host can directly connect to the Internet and provide the appropriate bandwidth to ensure a reasonable access response speed, another virtual host can provide a stable fixed IP.
A name-based virtual host can be built on any Web server by creating an alias for the IP address on the domain name server (DNS) and telling the Web server to distribute requests to different domain names to the corresponding Web page directory. Since this article is mainly about Tomcat, we're not going to introduce a way to set up DNS on a variety of operating systems, and if you need help with this, refer to DNS and Bind, the author of Paul Albitz and Cricket Liu (O ' Reilly). For demonstration convenience, I will use a static host file, because this is the easiest way to test the alias.
Using a virtual host in Tomcat, you need to set up DNS or host data. To test, setting an IP alias for a local IP is sufficient, and then you need to add a few lines to the Server.xml, as follows:
<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= "Ten" 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-->
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 "Virtual Host": http://www.example.com/-->
<context path= "" docbase= "." />
</Host>
</Engine>
</Service>
</Server>
Tomcat's Server.xml file, in its initial state, includes only one virtual host, but it is easily extended to support multiple virtual hosts. In the previous example, a simple Server.xml version was shown, where the bold part was used to add a virtual host. Each host element must include one or more context elements, one of which must be the default, and the display path for this default will be empty (for example, path= "").
5. Configure base validation (Basic authentication)
The container management authentication method controls how user identity is authenticated when a user accesses a protected Web application resource. When a Web application uses Basic authentication (the basic parameter is set in the Web.xml file Auto-method element), and when a user accesses a protected Web application, Tomcat passes through the HTTP basic Authentication way, a dialog box pops up asking the user to enter a username and password. In this authentication method, all passwords are transmitted over the network in 64-bit encoding.
Note: Using Basic authentication is considered unsafe because it does not have a robust encryption method unless you use HTTPS or other passwords on both the client and server side (for example, in a virtual private network). Without additional encryption methods, the network administrator will be able to intercept (or abuse) the user's password. However, if you are just starting out with Tomcat, or if you want to test your Web application for container based security management, Basic authentication is still very easy to set up and use. Just add <security-constraint> and <login-config> two elements to your Web application's Web.xml file, and in the Catalina_base/conf/tomcat-users.xml Add the appropriate <role> and <user> to the file, and then restart Tomcat.
The web.xml in the following example is excerpted from a club membership web system in which only the Member Directory is protected and authenticated using Basic authentication. Note that this approach will effectively replace the. htaccess file in the Apache Web server.
!--
Define the Members-only area by defining
A "security Constraint" in 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 (Sign-On)
Once you have set up the realm and authentication method, you need to do the actual user login processing. In general, it's a hassle to log on to a user system, and you have to minimize the number of user logon validations. As a default, when a user requests a protected resource for the first time, each Web application requires the user to log on. If you run more than one Web application, and each application requires a separate user authentication, it looks a bit like you're wrestling with your users. Users don't know how to integrate multiple discrete applications into a single system, and all of them don't know how many different apps they need to access, but are confused and why they always log on.
The "single sign-on" feature of Tomcat 4 allows users to log on only once when accessing all Web applications under the same virtual host. To use this feature, you only need to add a singlesignon valve element to the host, as follows:
<valve classname= "Org.apache.catalina.authenticator.SingleSignOn"
debug= "0"/>
After Tomcat's initial installation, Server.xml's comments include examples of singlesignon valve configurations that you can use only if you remove the annotations. Then, any user who logs on to an application is equally valid for all applications under the same virtual host.
There are some important limitations with single sign-on valve:
1> value must be configured and nested within the same host element, and all Web applications that require a single point of authentication (which must be defined through the context element) are located under that host.
2> including shared user information realm must be set up in the same level host or nested outside.
3> cannot be overwritten by realm in the context.
4> Web applications that use single sign-on are best to use a tomcat-built validation method (defined in <auth-method> in Web.xml), which is much more robust than custom validation, and the methods that are built into Tomcat include Basic, Digest, Form and Client-cert.
5> If you use single sign-on and you want to integrate a Third-party Web application into your site, and the new Web application uses its own authentication method without container-managed security, you're basically out of the way. Your users need to log on every time they log on to all applications and have to log in again when requesting a new Third-party application. Of course, if you have this third party Web application source code, and you are a programmer, you can modify it, but that is not easy to do.
6> single sign-on requires the use of cookies.
7. Configure user-defined directories (customized users directores)
Some sites allow individual users to publish Web pages on the server. For example, a college may want to give every student a public area, or an ISP would like to give some web space to his customers, but this is not a virtual host. In this case, a typical approach is to prefix the user name with a special character (~), as a site for each user, such as:
Http://www.cs.myuniversity.edu/~username
Http://members.mybigisp.com/~username
Tomcat provides two ways to map these personal sites on the host, using a unique pair of listener elements. The classname attribute of listener should be org.apache.catalina.startup.userconfig,userclass attribute should be one of several mapping classes. If your system is UNIX, it will have a standard/etc/passwd file in which the account number can be easily read by a running Tomcat, which specifies the user's home directory and uses the Passwduserdatabase mapping class.
<listener classname= "Org.apache.catalina.startup.UserConfig"
Directoryname= "Public_html"
userclass= "Org.apache.catalina.startup.PasswdUserDatabase"/>
Web files need to be placed under a directory like/home/users/ian/public_html or/users/jbrittain/public_html. Of course you can also change the public_html to any other subdirectory.
In fact, this user directory does not necessarily need to reside in the user's home directory. If you do not have a password file, but you want to map a user name to a common subdirectory like/home, you can use the Homesuserdatabase class.
<listener classname= "Org.apache.catalina.startup.UserConfig"
Directoryname= "public_html" homebase= "/home"
userclass= "Org.apache.catalina.startup.HomesUserDatabase"/>
As a result, Web files can be located in a directory like/home/ian/public_html or/home/jasonb/public_html. This form is more advantageous for Windows, and you can use a directory like C:\home.
These listener elements, if they occur, must be inside the host element, not within the context element, because they are all applied to the host itself.
8. Using CGI scripts in Tomcat
Tomcat is primarily used as a servlet/jsp container, but it also has many traditional Web server performance. Support for the Common Gateway Interface (Common Gateway Interface, CGI) is one of them, CGI provides a set of methods to run some extensions in response to browser requests. CGI is called generic because it can be invoked in most programs or scripts, including: Perl,python,awk,unix shell scripting, and even Java. Of course, you probably won't run a Java application as a CGI, after all, it's too primitive. In general, developing a servlet is always more efficient than CGI, because when a user clicks on a link or a button, you don't need to start processing from the operating system layer.
Tomcat includes an optional CGI Servlet that allows you to run legacy CGI scripts.
To enable Tomcat to run CGI, you have to do the following things:
1. Rename the Servlets-cgi.renametojar (under the catalina_home/server/lib/directory) to Servlets-cgi.jar. The servlet that handles the CGI should be located under Tomcat's classpath.
2. In Tomcat's Catalina_base/conf/web.xml file, remove the comment about the <servlet-name> CGI section (by default, the segment is on line No. 241).
3. Similarly, in Tomcat's Catalina_base/conf/web.xml file, remove the comment about the segment that maps the CGI (by default, the segment is on line No. 299). Note that this section specifies how HTML links to the CGI script are accessed.
4. You can place the CGI script in the web-inf/cgi directory (note that Web-inf is a safe place where you can put some files that you don't want to be seen by the user or are based on security considerations), or you can place the CGI scripts in other directories under the context. , and adjusts the Cgipathprefix initialization parameters for the CGI servlet. This specifies the actual location of the CGI servlet and cannot duplicate the URL specified in the previous step.
5. Restart Tomcat and your CGI will be ready to run.
In Tomcat, the CGI program is placed by default in the web-inf/cgi directory, and as previously indicated, the Web-inf directory is protected from prying into the contents of the client's browser, so for CGI scripts that contain passwords or other sensitive information, This is a very good place. In order to be compatible with other servers, although you can also keep CGI scripts in the traditional/cgi-bin directory, you know that files in these directories are likely to be seen by curious surfers on the web. In addition, in Unix, make sure that the user running Tomcat has permission to execute a CGI script.
9. Change the JSP compiler (JSP Compiler) in Tomcat
In Tomcat 4.1 (or later, presumably), the JSP's compilation is performed directly by the ant program controller contained within Tomcat. That sounds a little odd, but that's exactly what Ant is all about, and there's an API document that directs developers to use ant without starting a new JVM. This is a great advantage of using Ant for Java development. Also, this means that you can now use any JAVAC-supported compilation in Ant, and here is a Javac page list of Apache Ant manuals. It is easy to use because you only need to define a name named "Compiler" in the <init-param> element, and there is a compiler name in value that supports compilation, as shown in the following example:
<servlet>
<servlet-name> JSP </servlet-name>
<servlet-class>
Org.apache.jasper.servlet.JspServlet
</servlet-class>
<init-param>
<param-name> Logverbositylevel </param-name>
<param-value> WARNING </param-value>
</init-param>
<init-param>
<param-name> compiler </param-name>
<param-value> Jikes </param-value>
</init-param>
<load-on-startup> 3 </load-on-startup>
</servlet>
Of course, the compiler given must already be installed in your system, and classpath may need to be set up, and that execution is what compiler you choose.
10. Restricting specific host access (restricting access to specific hosts)
Sometimes you may want to restrict access to Tomcat Web applications, for example, if you want only the host or IP address you specify to access your application. As a result, only those clients that are specified can access the content of the service. To achieve this effect, Tomcat provides two parameters for you to configure: Remotehostvalve and Remoteaddrvalve.
By configuring these two parameters, you can filter the host or IP address from the request and allow or deny which hosts/IPs. Similarly, the httpd file in Apache has the Allow/deny designation for each directory.
For example, you can set the admin Web application to allow only local access, set as follows:
<context path= "/path/to/secret_files" ... >
<valve classname= "Org.apache.catalina.valves.RemoteAddrValve"
allow= "127.0.0.1" deny= ""/>
</Context>
If the host is not given a designation, the host that matches the rejected host will be rejected and otherwise allowed. Similarly, a host that matches a host is allowed if no designation is given to the host, except for the rejection.
