4. Configuring the virtual host (Virtual Hosts) About "Host" elements in Server.xml, only if you set the virtual host, you need to modify it. A virtual host is a mechanism for serving multiple domain names on a web server. For each domain name, it seems to have an exclusive host. In fact, most small business websites are implemented in virtual hosts, mainly because virtual hosts can connect directly to the Internet and provide corresponding bandwidth to ensure reasonable access response speed, and additional virtual hosts can provide a stable Fixed IP.
Name-based virtual hosts can be built on any web server, the method established is to create an alias of the IP address on the Domain Name Server (DNS), and tell the web server to distribute the request to different domain names to the corresponding web directory. Because this article is primarily tomcat, we don't prepare for the way DNS on various operating systems. If you need help in this regard, please refer to "DNS and Bind" book, the author is Paul Albitz and cricket Liu ( O'Reilly. For the convenience of demonstration, I will use a static host file because it is the simplest method for testing alias.
Using a virtual host in Tomcat, you need to set DNS or host data. In order to test, set an IP alias for local IP. Next, you need to add a few lines of content in Server.xml, as follows:
Port = "8080" MINPROCESSORS = "5" maxprocessors = "75" Enablelookups = "True" redirectport = "8443" /> Port = "8443" MINPROCESSORS = "5" maxprocessors = "75" Acceptcount = "10" debug = "0" scheme = "https" secure = "true" /> ClientAuth = "false" protocol = "tls" /> Reloadable = "true" crossText = "true"> Tomcat's server.xml file, in the initial state, only a virtual host, but it is easy to expand to multiple virtual hosts. A simple server.xml version is shown in the previous example, where the bold part is used to add a virtual host. Each Host element must include one or more context elements that must have a default context, which should be empty (for example, path = "). 5. Configuring basic authentication (Basic Authentication) The container management verification method controls how to identify the user's identification when the user accesses the protected web application resource. When a web application uses the Basic Authentication (the Basic parameter is set in the auto-method element in the web.xml file), and when a user access protected web app, Tomcat will pop up a dialog box, request The user enters the username and password. In this verification method, all passwords will be transmitted on the network with a 64-bit encoding. 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 there is no additional encryption method, the network administrator will be able to intercept (or abuse) the user's password. However, if you just start using Tomcat, or you want to test the container-based security management in your web application, Basic Authentication is also very easy to set up and use. Just add with Two elements into the web.xml file for your web application, and add appropriate in the Catalina_Base / Conf / Tomcat-Users.xml file with That's, then restart Tomcat. The web.xml in the following example is taken from a club member website system, which is only protected by the Member directory and authenticated using Basic Authentication. Note that this way will effectively replace the .htaccess file in 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. -> Entire Application 6. Single sign-on (SINGLE SIGN-ON) Once you set up Realm and verification, you need to perform actual user login processing. Generally speaking, the login system for users is a very troublesome thing, you must try to minimize the number of users login verification. As the default, when the user first requests protected resources, each web application requires a user to log in. If you have run multiple web applications, and each application needs to perform separate user authentication, then it looks a bit like you fight with your users. Users don't know how to integrate multiple separate applications into a separate system. All they don't know how many different applications they need, but they are only confused, why should they always log in. Tomcat 4's "Single Sign-ON" feature allows users to log in once when accessing all web applications under the same virtual host. In order to use this feature, you only need to add a SingLesignon Valve element on Host, as shown below: Debug = "0" /> After the initial installation of Tomcat, the Note of Server.xml includes examples of the SingLesignon Valve configuration, you only need to remove the comment, you can use it. Then, any user will be equally valid for all applications under the same virtual host. There are some important limits using Single Sign-on Valve: 1> Value must be configured and nested in the same Host element, and all web applications that need to be single-point validation (definition must be defined via the context element) is located under this host. 2> Realm including shared user information must be set in the same stage Host or outside the nest. 3> Can't be covered by Realm in Context. 4> Using a single-point login web app to best use a Tomcat built-in verification method (defined in web.xml Middle), which is stronger than the custom verification method, and Tomcat has built-in verification methods include Basic, Digest, Form, and Client-Cert. 5> If you use a single sign-on, you want to integrate a third-party web application to your website, and this new web application uses its own verification mode, without using container management security, then you basically No trouble. Your users need to log in every time all applications are logged in, and they have to log in again when requested new third-party applications. Of course, if you have the source code for this third party web application, and you are a programmer, you can modify it, but it is not easy to do. 6> Single sign-on needs to use cookies. << Previous 1 2 3 Next >>
