Setting the Site URL of a MIRC Site
This article describes how the Site URL field on the Query Service Admin page affects the way users access MIRCdocument. This article is intended for MIRC site administrators. It was written to provide an explanation for and the solution to a problem where a user logs into the main query page, queries for documents, and is then asked to log in again when trying to display a document.
The Query Service maintains a list of Storage Services that it can query. Each Storage Service is identified by, among other things, a URL. When the Query Service receives a set of query results from a Storage Service, it constructs the query results page to send to the user. The query results page presents a list of documents, where each item in the list is a link to the document on the Storage Service. The Query Service constructs the link from the URL which the Query Service has for the Storage Service and the relative link provided by the Storage Service to get to the document.
Now imagine that the user knows the Query Service by the URL http://myuniversity.edu/mirc/query, and the Query Service knows a local Storage Service by the URL http://192.168.0.2/storage/service. The two URLs point to the same instance of Tomcat.
So, the user goes to the Query Service with the domain-name URL and logs in. The browser gets a single sign-on cookie back from Tomcat providing session authentication. The browser stores that cookie under the domain-name URL that it used to access the Query Service and automatically supplies that cookie on all subsequent accesses to that URL during the session. The user then submits the query form to the Query Service. The Query Service does an HTTP POST of the MIRCquery to the Storage Service using the IP-address URL and receives a set of query results. The Query Service constructs the query results page, creating links based on the IP-address URL of the Storage Service. The user clicks one of the links. The browser does an HTTP GET of the URL in the link, but the browser does NOT send the session cookie because it doesn't have one stored under that URL -- it has one for the same Tomcat, but under the domain-name URL, and browsers don't realize that they are the same. The result is that the Storage Service which receives the HTTP GET for the document doesn't get any session authentication information, so it thinks the user is not authenticated, and if the requested document is protected, the Storage Service routes the request to the Login servlet for authentication before it serves the document. The core reason that two logins are required in this situation is that the user is accessing the same Tomcat using two different URLs.
To prevent this problem from occurring, look at the "Site URL" field on the Query Service Admin page. Make sure that it is the same as the URL by which users access the MIRC site. If you have to change it, make sure you click the "Update mirc.xml" button at the bottom of the page and then restart Tomcat. When Tomcat restarts, go back to the Query Service Admin page and look at the table of Storage Services at the bottom. Make sure that the URLs of all the local Storage Services correctly reflect the change.
There are a couple of subtleties having to do with the address type (static or dynamic). On a site operated with dynamic addressing, if the Site URL field is a numeric IP address, MIRC automatically obtains the IP address from the operating system when it starts, and it updates the Site URL field and the IP addresses of all the local Storage Services. If the address type is static, or if the Site URL field is not numeric, the URLs are not changed.
On a MIRC site that is to be accessed from other computers on the network, the best approach is to get a domain-name URL for the site and put it in the Site URL field and in all the URLs of the local Storage Services. If no domain-name URL is available, then an IP URL can work. In this case, it is best to get a fixed IP address from the network admimistrator; that way, bookmarks and shortcuts which reference MIRCdocuments will always work. (Clearly, if you make a bookmark to a MIRCdocument based on an IP address and the IP address changes, the link is broken. Domain-name URLs don't have that problem because they are resolved each time the document is accessed.)
On a MIRC site that is intended to be accessed only from the computer on which the MIRC site is running, the best approach is to use 127.0.0.1 as the IP address and set the address type to static.