ColdFusion Article

ColdFusion 8 server monitoring – Part 4: Multiserver Monitor, Admin API monitoring, and more

Some possible challenges using the Multiserver monitor

That's it for the interface features of the Multiserver Monitor. Still, there are few challenges in using the tool that you might encounter.

Securing the monitoring of your server

As you contemplate the power of this tool to watch any CF8 Enterprise or Developer edition server, you may wonder just how one can limit which servers can be monitored, or rather, how can you keep someone else from monitoring your own server?

Of course, you saw earlier in adding a new server to the Multiserver Monitor that one needs to know an administrator username and password for the server to be monitored, but for many that's simply not enough security. You might want to prevent your server from being monitored at all.

Here's good news: By default, the Multiserver Monitor can only monitor the server from which it's launched. It's not that you can't monitor other servers, of course, but for security reasons, a Flash movie playing in a web browser is not allowed to access data that resides outside the exact web domain from which the SWF file originated. That's comforting news to the security-conscious, but it can also be a hindrance as you try to add new servers you want to legitimately monitor, if you're not expecting it. How do you enable it if desired?

Understanding the multiservermonitor-access-policy.xml file

For a ColdFusion server to be monitored by a Multiserver Monitor running on a different domain, you must take an extra step regarding the configuration of that server to be monitored. Here's an example: The Multiserver Monitor loaded from server A on firstdomain.com cannot monitor Server B on seconddomain.com, unless Server B is configured to permit requests from firstdomain.com. Specifically, the multiservermonitor-access-policy.xml for the ColdFusion server running on Server B of seconddomain.com must be configured to permit monitoring from firstdomain.com.

In the stand-alone deployment mode of ColdFusion, this multiservermonitor-access-policy.xml file would be found in the \coldfusion8\wwwroot\CFIDE directory, if you installed ColdFusion to use its built-in web server, or in the \CFIDE directory within a webroot directory of your external web server if you've configured ColdFusion to use one. Again, this is the directory where your ColdFusion Administrator is configured for the ColdFusion server. Similarly, in the Multiserver deployment, this would be in the deployed instance, such as \JRun4\servers\cfusion\cfusion-ear\cfusion-war\CFIDE, if using the built-in web server

The file has just one significant line, commented out by default:

<!--  <allow-access-from domain="*" />    -->

With it commented out, it means that requests from a Multiserver Monitor in another domain are denied. If un-commented, it would permit monitoring from Multiserver Monitors running on any domain at all (this is something you would never want).

If you want to permit the Multiserver Monitor on another domain to access this server, un-comment the line and name in the domain attribute the domain (or IP address) for that remote server. (Note that this is not about adding the IP address of the client who is running the Multiserver Monitor, but rather the server running the Multiserver Monitor!)

For instance, if the server at seconddomain.com wanted to permit monitoring from the Multiserver Monitor running at firstdomain.com, seconddomain.com's xml file could be modified to have the line:

<allow-access-from domain="firstdomain.com" />

The Flash security model uses the exact domain name, so it's important to note that while this would permit access from a Multiserver Monitor loaded from http://firstdomain.com, it would not permit access if the monitor was run from www.firstdomain.com. If that's the actual domain from which you want to run the Monitor, you should instead specify the domain value either as http://www.firstdomain.com or note that you can use a wildcard, as in *.firstdomain.com. You cannot use wildcards for IP addresses.

If you want to permit access from multiple different domains, note that you can specify multiple entries to name multiple remote domains, such as:

<allow-access-from domain="*.firstdomain.com" />
<allow-access-from domain="*.thirddomain.com" />

You can learn more about this sort of cross-domain xml file, which has long existed for use with Flash applications, in the TechNote 14213: External data not accessible outside a Flash movie's domain. While it discusses crossdomain.xml files in particular, this multiservermonitor-access-policy.xml is merely a differently-named version of such a file. (The cross-domain issues apply only to the Multiserver Monitor, because as a Flash-based interface it can communicate with a server other than that from which it's requested. The Server Monitor, while also a Flash-based interface, communicates only with the server from which it's requested.)

You can edit this multiservermonitor-access-policy.xml file and it will take effect immediately, without needing to restart either the server being monitored or the one doing the monitoring.

Be careful with browser caching and the cross-domain file

Although the change above takes effect immediately, there is a potential gotcha with browser caching.

Let's explain it in the context of adding a new server to the Multiserver Monitor list of servers (Figure 3). If you add a remote server before making this cross-domain policy change on that remote server, the box shown in the Multiserver Monitor (as shown in Figure 5) will display the words Permission Denied in its Status line, because you had not yet made the cross-domain configuration change.

Once you make the change, however, the error may not go away immediately. The problem is that the browser (the one showing the Multiserver Monitor) will have cached its request for that XML file. The Flex/Flash-based application that is the Multiserver Monitor requests this file from the remote server to determine if it's permitted to access it remotely this way, and it saves it for future requests.

You can manually view the remote server's XML file using a URL such as:

http://[servername]/flex2gateway/multiservermonitor-access-policy.xml

If you do that and it shows the proper values have been set, yet the Monitor still won't permit access and showing the error in the status line, you need to force the browser to refresh the SWF file showing the Multiserver Monitor. This is a challenge common to Flex/Flash-based web applications pulling data from a remote web server related to interaction with built-in browser caching features (which can very between browsers and depending on options set within the browser by the user.)

In most browsers you can force the browser to refresh a file it's requested by holding the Shift key while refreshing (using the mouse to click the refresh button or clicking Control-R). If that doesn't work, there are still other techniques which may help (passing random query strings, using HTTP proxy tools to analyze the problem) but since it's likely you will add servers infrequently, you can also just close the browser (perhaps all instances of it) and reopen it, and then run the Multiserver Monitor.

It's worth noting about this cross-domain policy issue that, to Flash (and the monitor), domain names and IP addresses are not resolved as being identical, even if the browser sees them as such. As a test, you'll find that if you view your localhost Multiserver Monitor (as in http://localhost/CFIDE/administrator/monitor/launch- multiservermonitor.cfm), and then try to add your local server to the Multiserver Monitor using 127.0.0.1 as the "server" field (as in Figure 1), this too will fail initially. You must add localhost as a permitted domain in the cross-domain file discussed above (or vice, versa, if you browsed it as localhost but added the server as 127.0.0.1, in which case you'd need to use localhost for the "Server"field.).

Multiserver Monitor configuration is stored per the domain used to open it

To wrap up this presentation of the Multiserver Monitor, and especially with regard to trying to access a server by both its domain name and IP address, there's a related but very different concern when it comes to how you request the Multiserver Monitor in your browser.

If you browse the Multiserver Monitor through one domain name (like localhost), and configure it to watch various servers, and then browse the Multiserver Monitor again but through that server's IP address (like 127.0.0.1) or another domain name (like your real servername) as compared to the first one, it will show the Multiserver Monitor, but all your configuration settings (like the list of servers you previously configured) will be lost. Why is that?

As a Flash/Flex application, the Multiserver Monitor is a client-side application that talks to back-end servers. It needs a place to store the configuration information entered, and like most Flash/Flex applications, it uses Flash SharedObjects (as an alternative to cookies) to save the configuration information you've entered. SharedObjects are stored on the local disk of the user viewing the monitor, and they are also unique per domain (or IP address) used to launch the SWF file, which explains the problem. Launching the Multiserver Monitor with different URLs (on the same server) will therefore have different configuration settings.

Page 3 of 6

Previous Page

Next Page