A configuration management system (Admin Web Application)
Most commercial J2EE servers provide a powerful management interface, and the mostly easy to understand Web application interface. Tomcat in its own way, also provides a sophisticated management tool, and is in no way inferior to those of commercial competitors. Tomcat's Admin Web Application originally appeared in the 4.1 version, that includes the functions management context, data source, user and group and so on. Of course, management can be as initialization parameters, user, group, role in a variety of database management. In subsequent versions, these functions will be greatly expanded, but the existing functionality has been very practical. Admin Web ApplicationAutomatic deployment is defined in the file: CATALINA_BASE/webapps/admin.xml. (Translator's Note: CATALINA_BASE That tomcat server installation directory under the directory)
You must edit this file to determine docBase Context parameter is an absolute path. In other words, CATALINA
_BASE/webapps/admin.xmlThe path is an absolute path. Alternatively, you can also delete the file automatically deployed, and establish a Admin Web Application of context in the server.xml file, the effect is the same. You can not manage Admin Web Application of this application, in other words, in addition to delete CATALINA_BASE / webapps / admin.xml, you probably can not do anything.
If you use UserDatabaseRealm (default), you will need to add a user and a role to CATALINA_BASE/conf/tomcat-users.xmlfile. You edit this file, add a name of "admin" role to the file, as follows:
<role name="admin"/>The same need for a user, and the user's role is "admin". As the user, add a user (change their passwords more secure):
<ser name="admin"password="deep_dark_secret"roles="admin"/>After you have completed these steps, restart Tomcat, visit http://localhost:8080/admin, you will see a login screen. Admin Web Application using container-managed security mechanisms based and uses Jakarta Struts framework. Once you log in as a user management interface "admin" role, you will be able to use the management interface to configure Tomcat.
Second, the application configuration management (Manager Web Application)
Manager Web Application lets you easier than by a Admin Web Application user interface, perform some simple Web application tasks. Manager Web Application is defined in the deployment of an automated file:
CATALINA_BASE/webapps/manager.xmlYou must edit this file to ensure docBase context parameter is an absolute path, that is the absolute path CATALINA_HOME / server / webapps / manager of. (Translator's Note: CATALINA_HOME That tomcat installation directory)
If you are using UserDatabaseRealm, then you need to add a user to a role and CATALINA_BASE / conf / tomcat-users.xml file. Next, edit the file, add a role "manager" named to the file:
<role name=”manager”>Also you need to have a role as "manager" of the user. Like the user already exists, add a new user (change their passwords more secure):
<user name="manager"password="deep_dark_secret"roles="manager"/>Then restart Tomcat, visit http://localhost/manager/list, you will see a very simple text-based management interface, or access to http://localhost/manager/html/list, you will see a HMTL management interface. Either way you have explained the Manager Web Application has now started.
Manager applicationSo that you can not on the basis of administrative privileges on the system, install a new Web application for testing. If we have a new web application in / home / user / hello in, and want to install it to the next / hello, in order to test this application, we can do so, enter "/ hello" in a file box (a visit to the path), in the second text box, enter " file:/home/user/hello" (as Config URL).
Manager applicationAlso allows you to stop, restart, remove and re-deploy a web application. Stopping an application so that it can not be accessed when a user tries to access the application is stopped, you will see a 503 error ?? "503 - This application is not currently available".
Remove a web application, only to delete the application from running copy of Tomcat, if you restart Tomcat, the application will be deleted again (that is, the removal does not mean deleted from the hard).
Third, the deployment of a web application
There are two ways you can deploy web service in the system .
- Copy your WAR file or your web application folder (including all elements of the web) to under $ CATALINA_BASE / webapps directory.
- As you build a web service XML fragment includes only the contents of the file context and put the file into the
$CATALINA_BASE/webappsdirectory. This web application itself can be stored anywhere on your hard drive.
If you have a WAR file, you deploy it if you want, you only need to copy the file to the next simply CATALINA_BASE / webapps directory can file must be ".war" extension. Once Tomcat listening to this document, it (the default) to unlock the package as a subdirectory and file name of the WAR file as the name of a subdirectory.
Next, Tomcat will create a context in memory, the same as if you build in the server.xml file. Of course, other essential content, from server.xml in DefaultContext obtained.
Another way to deploy a web application is to write a Context XML fragment file, then copy the file to the CATALINA_BASE / webapps directory. Context is not a piece of a complete XML file, but only one element, and the corresponding description of the application context.
As this document is like clips cut out of the context in server.xml elements, so this piece is named "context fragment."
For example, if we want to deploy the application named MyWebApp.war of the application using the realm as access control, we can use the following snippet:
<!--Context fragment for deploying MyWebApp.war-->
<Context path="/demo"docBase="webapps/MyWebApp.war"debug="0" rivileged="true">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"resourceName="UserDatabase"/>
</Context>The fragments were named "MyWebApp.xml", and then copied to CATALINA_BASE / webapps directory.
This context clips provide a convenient way to deploy a web application, you need to edit server.xml, Tomcat restart is not required unless you want to change the default deployment features, install a new web application.
Fourth, configure a virtual host (Virtual Hosts)
About the server.xml "Host" this element, only if you set up a virtual host only needs to be modified. Web Hosting is a mechanism in a web server serving multiple domains, for each domain name, it seems to have a whole host exclusive. In fact, most small business websites are using virtual hosts to achieve, mainly because of the virtual host can be connected directly to the Internet and provide the appropriate bandwidth to ensure reasonable access speed of response, while also providing a stable web hosting fixed IP.
Name-based virtual host can be built on any web server, established method is through the establishment of an alias IP addresses on the domain name server (DNS), and tell the web server to distribute destined for a different domain name requests to the appropriate web directory. Because this article is mainly about Tomcat, we are not ready to introduce the DNS settings on a variety of operating systems approach, if you need help in this regard, please refer to the "DNS and Bind" a book, the author is Paul Albitz and Cricket Liu ( O'Reilly). In order to facilitate the demonstration, I will use a static hosts file, because this is the easiest way to test alias.
Use virtual hosts in Tomcat, you need to set up DNS or host data. To test, set up a local IP IP alias is enough, then you need to add a few lines in 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="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, in the initial state, only includes a virtual host, but it can easily be expanded to support multiple virtual hosts. Demonstrated in the previous example is a simple server.xml version, where the bold part is used to add a virtual host. Host each element must include one or more context elements, context elements included must be a default context, the context of the display default path should be empty (e.g., path = "").
Fifth, configure basic authentication (Basic Authentication)
Container-managed authentication method controls when the user accesses the web application resource protection, how to identify the user's identity. When a web application uses Basic Authentication (BASIC parameter auto-method element is set in the web.xml file), while users to access protected web applications, Tomcat HTTP Basic Authentication by the way, pop up a dialog box asking user to enter a user name and password. In this authentication method, the password is transmitted to all the 64-bit encoding on a network.
Note: By using Basic Authentication is considered unsafe because it does not have strong encryption, unless use HTTPS or other code on the client and server-side encrypted manner (for example, in a virtual private network). If no additional encryption, network administrators will be able to intercept (or abuse) the user's password.
However, if you are just getting started with Tomcat, or you want to test your web applications for security management at the container, Basic Authentication is still very easy to set up and use. And only need to add two elements to the web.xml file of your web application, and add the appropriate and can be in CATALINA_BASE / conf / tomcat-users.xml file, then restart Tomcat.
The following example is taken from a web.xml club membership site system only member directory is protected, and use Basic Authentication for authentication. Please note that in this way will effectively replace the .htaccess files 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>Sixth, configure single sign-on (Single Sign-On)
Once you've set the realm and methods of verification, you'll need the actual user login process. In general, for the user login system is a very troublesome thing, you have to minimize the number of user login authentication. As a default, the first time a user requests a protected resource, each web application will require the user to log on.
If you run multiple web applications, and each application requires a separate user authentication, then it looks a bit like you're wrestling with your users. Users who do not know how to integrate a number of separate applications into a single system, all they do not know how many different applications they need to access, just very confused, why do you want to keep login.
When Tomcat "single sign-on" 4 features allow users to access the same virtual host in all web applications, a single login. To use this feature, you only need to add on the Host a SingleSignOn Valve element, as shown here:
<Valve className="org.apache.catalina.authenticator.SingleSignOn"debug="0"/>After initial installation Tomcat, which includes examples of the server.xml Notes SingleSignOn Valve configuration, you only need to remove comments, can be used. So, as long as any user logged into an application, the same is valid for all applications in the same virtual host. There are some important limitations to use single sign-on valve:
- value must be in the same configuration and nested in the Host element, and a single point is required to verify all of the web application (to be defined by the context elements) are located in the Host.
- Including the sharing user information must be disposed outside the realm with a Host or nested.
- Context can not be covered in the realm.
- Single sign-on web applications is preferable to use the built-in authentication (defined in web.xml) is a Tomcat, which is stronger than the authentication custom, built-in authentication methods Tomcat include basic, digest, form and client-cert.
- If you use a single sign-on, also want to integrate a third-party web application to your site in the past, and this new web application uses its own authentication methods, without the use of container managed security, then you basically have no trick a. You need to log in each time a user login time when all of the original application, and have to log in again when requesting new third-party applications.
Of course, if you have the third-party source web application, and you are a programmer, you can modify it, but I am afraid that is not easy to do. - Single sign-on requires the use of cookies.
Seven, custom configuration directory (Customized User Directores)
Some sites allow individual users to publish Web pages on the server. For example, a university institute may want to give each student a public area, or an ISP web space to give some hope to his customers, but this is not a virtual host. In this case, a typical method is to add a user name in front of a special character (~), as each user site, such as:
http://www.cs.myuniversity.edu/~username
http://members.mybigisp.com/~usernameTomcat provides two methods to map these personal websites on the host, primarily using a pair of special Listener elements. The Listener className attribute should be org.apache.catalina.startup.UserConfig, userClass property should be one of several mapping classes.
If your system is Unix, it will have a standard / etc / passwd file, which the account can be easily read running Tomcat, the file specifies the user's home directory, use 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 in the following directory like / home / users / ian / public_html or / users / jbrittain / public_html the same. Of course, you can also change the public_html to any other subdirectory.
In practice, the user directories simply do not necessarily need to be located inside the user's home directory. If you do not have a password file, but you want a user name is mapped to the public subdirectory like / home the same directory, you can use HomesUserDatabase class.
<Listener className=
"org.apache.catalina.startup.UserConfig"
directoryName="public_html"
homeBase="/home"
userClass="org.apache.catalina.
startup.HomesUserDatabase"/>As a result, web file can be located in as / home / ian / public_html or / home / jasonb / public_html the same directory. This form is more favorable for Windows, you can use like a c: \ This directory home.
Listener these elements, if present, must be in Host elements inside, but not in the context of elements which, because they apply to Host with itself.
Eight, the use of CGI scripts in Tomcat
Tomcat primarily as a Servlet / JSP container, but it also has many traditional web server performance. Supports the Common Gateway Interface (Common Gateway Interface, i.e. CGI) is one of them, CGI provides a set of methods to run some extension in response to a browser request.
CGI are called universal, because it can be called in most programs, or scripts, including: Perl, Python, awk, Unix shell scripting, and even include Java.
Of course, you probably will not put a Java application as a CGI to run, after all, is too primitive. In general, the development of Servlet CGI than to have better efficiency, because when a user clicks on a link or a button, you do not need to start the process from the operating system layer.
Tomcat includes an optional CGI Servlet, CGI script allows you to run a legacy.
In order to be able to run Tomcat CGI, you must do the following things:
- The servlets-cgi.renametojar (in CATALINA_HOME / server / lib / directory) renamed servlets-cgi.jar. CGI servlet process should be in the Tomcat CLASSPATH.
- In the Tomcat CATALINA_BASE / conf / web.xml file, the notes on that part of CGI removed (by default, the segment at line 241).
- Similarly, in the Tomcat CATALINA_BASE / conf / web.xml file, the notes on that part of the mapping of the CGI removed (by default, the segment at line 299). Note that this content is specified HTML link to access the way to the CGI script.
- You can put CGI scripts placed in the WEB-INF / cgi directory (note, WEB-INF is a safe place where you can put some do not want to be seen or safety reasons do not want to expose files on the user here), or you CGI scripts can also be placed in other directories under the context, and adjust cgiPathPrefix initialization parameters for the CGI Servlet. This is the actual position of the specified CGI Servlet, and can not step on the URL specified by the same name.
- Restart Tomcat, you can run the CGI.
In Tomcat, CGI program default placed in the WEB-INF / cgi directory, as previously suggested that, WEB-INF directory protected by the client's browser can not pry into its contents, so for placement contain passwords or CGI scripts and other sensitive information, this is a very good place.
For compatibility with other servers, although you can also put CGI scripts stored in the traditional / cgi-bin directory, but you know, files in these directories are likely to be curious Web surfers to see. In addition, Unix, make sure the user has permission to run Tomcat execute CGI scripts.
Nine, change the Tomcat JSP compiler (JSP Compiler)
In Tomcat 4.1 (or later, probably), JSP compilation performed directly by the Ant program controller included in the Tomcat inside. This sounds a little strange, but that is part of Ant whom intentional, there is an API documentation to guide developers in the absence of starting a new JVM using Ant.
This is a big advantage using Ant for Java development. In addition, this also means that you can now use any Ant javac support in compiling the way, here's a list of Apache Ant javac page user manual.
Is easy to use, because you only need to define the elements of a name "compiler", and there is a compiler compiler name support in value, the examples are as follows:
<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, given the compiler must be installed in your system, and may need to set CLASSPATH, then executed on your choice of what kind of compiler.
Ten, restrict access to specific hosts (Restricting Access to Specific Hosts)
Sometimes, you may want to limit access to the Tomcat web application, for example, you want only that you specify the host or IP address can access your applications. As a result, only those specified by the client can access the content and services. To achieve this effect, Tomcat provides two parameters for your configuration: RemoteHostValve and RemoteAddrValve.
By configuring these two parameters, allowing you to filter requests from the host or IP address, and allows or which hosts / IP refused. Similarly, there is for each directory allow / deny specified in the Apache httpd file. For example, you can set the Admin Web application to allow only local access, as follows:
<Context path=
"/path/to/secret_files" ...>
<Valve className="org.apache.
catalina.valves.RemoteAddrValve"
allow="127.0.0.1" deny=""/>
</Context>If no permit specified host, then refused to host matches with the host will be rejected, other than are allowed. Similarly, if the specified host rejection is not given, and it will be allowed to allow the host to host matches, in addition are rejected.
————END————
