Admin Web Application

Most commercial J2EE servers provide a powerful management interface, and most use easy-to-understand Web application interfaces. Tomcat, in its own way, also offers a mature management tool, no less than its commercial competitors. Tomcat’s Admin Web Application first appeared in version 4.1, with functions such as managing context, data source, user, and group. Of course, it can also manage various database management such as initialization parameters, user, group, role, etc. These features will be greatly expanded in future releases, but the existing features are already very useful. The Admin Web Application is defined in the automatic deployment file CATALINA_BASE/webapps/admin.xml. You must edit this file to make sure that the docBase parameter in the Context is the absolute path. That is, the path to CATALINA_BASE/webapps/admin.xml is an absolute path. Alternatively, you can delete the automatic deployment file and create an Admin Web Application context in the server.xml file, which has the same effect. You can’t manage Admin Web Application; in other words, you probably can’t do anything except delete CATALINA_BASE/webapps/admin.xml. If you use UserDatabaseRealm (the default), you will need to add a user and a role to CATALINA_BASE/conf/tomcat-users.xml. [size=0.85em]
You also need to have a user, and the role of this user is “admin”. Add a user like an existing user (change password to make it more secure) : [size=0.85em]
After you have completed these steps, please restart Tomcat, Visit http://localhost:8080/admin, you will see a login screen. The Admin Web Application uses container-managed security mechanisms and the Jakarta Struts framework. Once you log in to the admin interface as an “admin” user, you will be able to configure Tomcat using the admin interface. Manager Web Application

Manager Web Application lets you perform simple Web Application tasks through a simpler user interface than Admin Web Application. The Manager Web Application is defined in an automatic deployment file: [size=0.85em]CATALINA_BASE/webapps/manager.xml You must edit this file to make sure that the context’s docBase parameter is an absolute path, That is to say the CATALINA_HOME/server/webapps/manager the absolute path. If you are using UserDatabaseRealm, 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: [size=0.85em]

Also need to have a user with role “manager”. Add a new user like an existing user (change the password to make it more secure) : [size=0.85em]
Visit http://localhost/manager/list, will see a very plain text type management interface, or visit http://localhost/manager/html. , you will see an HMTL administration interface. Either way, your Manager Web Application is now up. Manager Application lets you 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, to test the application, we can do this by typing “/hello” in the first file box (as the path to access), Enter “file:/home/user/hello” (as the Config URL) in the second text box. Manager Application also allows you to stop, restart, remove, and redeploy a Web application. Stop an application so that it cannot be accessed. When a user attempts to access the stopped application, he/she will see a 503 error. “503 – This application is not currently available”. Removing a Web application simply means removing it from the running copy of Tomcat, and if you restart Tomcat, the deleted application will reappear (i.e., removing does not mean removing it from the hard disk). Deploy a Web application

There are two ways to deploy Web services on your system. Copy your WAR file or your Web application folder (including all the contents of the Web) to

Orders,
record
Under the
.
for
you
the

clothing
service
build
state
one
a
only
package
enclosed

Within the
let
the

slice
broken
wen
a
.
and
the
the
wen
a
put
to












































The “Host” element in server.xml needs to be changed only when you set up a virtual Host. Virtual hosting is a mechanism for serving multiple domain names on a Web server, and for each domain name, it seems to own the whole host. In fact, most of the small business websites are implemented by virtual host, which is mainly because the virtual host can directly connect to the Internet and provide the corresponding bandwidth, in order to ensure a reasonable access response speed, and virtual host can also provide a stable fixed IP. Name-based virtual hosts can be created on any Web server by aliasing IP addresses on the Domain name Server (DNS) and telling the Web server to distribute requests to different domains to the corresponding web directory. Since this article is mainly about Tomcat, we are not going to cover setting up DNS on various operating systems. If you need help with this, please refer to DNS and Bind by Paul Albitz and Cricket Liu (O’Reilly). For demonstration purposes, I’ll use a static host file, as this is the easiest way to test aliases. To use virtual hosting in Tomcat, you need to set up DNS or host data. To test this, it is enough to set an IP alias for the local IP. Next, you need to add a few lines to server.xml like this: [size=0.85em]






Tomcat server. XML file, in its initial state, contains only one virtual host, but it can easily be extended to support multiple virtual hosts. Shown in the previous example is a simple version of server.xml, where bold is used to add a virtual host. Each Host element must contain one or more context elements, and one of the contained context elements must be the default context, whose display path should be empty (for example, path= “”). 5. Configure Basic Authentication

Container-managed authentication controls how users are authenticated when they access protected Web application resources. When a Web application uses Basic Authentication (the Basic parameter is set in the auto-method element of the web. XML file) and a user accesses the protected Web application, Tomcat will pop up a dialog asking the user to enter a user name and password via HTTP Basic Authentication. In this authentication method, all passwords are transmitted over the network in 64-bit encoding. Note: Using Basic Authentication is considered insecure because it does not have robust encryption methods unless HTTPS or another password-plus password is used on both the client and server (for example, in a virtual private network). Without additional encryption methods, network administrators can intercept (or abuse) users’ passwords. However, Basic Authentication is very easy to set up and use if you are just starting out with Tomcat or if you want to test container-based security management in your Web application. Simply add and to your web application’s web. XML file, add the appropriate and to CATALINA_BASE/conf/tomcat-users. XML file, and restart Tomcat. The web.xml in the following example is taken from a club membership web site system where only the member directory is protected and authenticated using Basic Authentication. Note that this effectively replaces the.htaccess file in the Apache Web server. [size = 0.85 em]




Entire Application


/members/*




member



BASIC


My Club Members-only Area