3. Deploy a Web applicationThere 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) into the $catalina_base/webapps directory.
2. Create an XML fragment file that includes only the context content for your Web service and place 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 ". War "as an extension. Once
TomcatHearing this file, it will (by default) unlock the package as a subdirectory and use the file name of the war file as the subdirectory's name.
Next
TomcatA context will be created in memory as if you were 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
-->
Docbase= "Webapps/mywebapp.war"
debug= "0" privileged= "true" >
"Org.apache.catalina.realm.UserDatabaseRealm"
Resourcename= "Userdatabase"/>
|
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, install a new Web application without needing to reboot
Tomcat.
4. Configure Virtual HostAbout 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. Because this article is mainly about
Tomcat, we are 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.
In
TomcatYou need to set up DNS or host data by using a virtual host. 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-->
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" crossc>
</Context>
</Host>
!--This Host is the
"Virtual Host": http://www.example.com/-->
Appbase= "/home/example/webapp" >
<context path= "" docbase= "." />
</Host>
</Engine>
</Service>
</Server> |
TomcatServer.xml file, in the 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 Basic authentication (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 a user accesses a protected Web application,TomcatA dialog box will be displayed via HTTP Basic authentication to require 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.
But if you're just starting to useTomcat, 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/ Add the appropriate <role> and <user> to the Tomcat-users.xml file, and then restartTomcat.
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 be effective in lieu of the Apache Web server. htaccess files.
!--
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.
-->
Entire Application
/members/*
member
!--Define the Login
Configuration for
This application-->
BASIC
my Club
Members-only Area
|
|
|
