12.3. Setting Up XPFE for Remote Applications
Remote Mozilla applications are limited because they cannot access and use some of the rich functionality provided in XPCOM interfaces. Unless you make the privilege change described in this section, access to XPCOM via XPConnect in your web page or remote application is forbidden. This privilege modification set up by the remote application developer grants complete access to the Mozilla functionality, to resources in the chrome, and to the host system via the Mozilla components that handle such tasks as File I/O. Of course, making this change means that the files on your server could be read, written to, or deleted, which is why rights are restricted by default. We recommend that you grant this extended privilege only when you do not have valuable data on the server or if you have taken steps to ensure that the data cannot be accessed.
The privilege, called Universal XPConnect, can be turned on from the Privilege Manager, which is a property of the netscape.security object. Example 12-2 shows a script that turns this privilege on and then uses new found privilege to create XPCOM component instance.
You can also turn on this privilege in your profile user preference file with the following line:
enablePrivilege("UniversalXPConnect"); | A script with this kind of plate-cleaning power can only be run successfully when it's executed locally, as from a local XUL file with a <DEFANGED_script> element. To open up XPConnect remotely with JavaScript like this, you have to use a signed script (see the section Section 12.6 in this chapter). |
Once this privilege is enabled, remote XUL applications can run as if they are local. Remote files can use any Mozilla component, reuse skin resources, XBL widgets, and whatever else the browser uses.
12.3.1. Server Configuration
Proper configuration of the XUL MIME type on your web server is necessary to serve remote Mozilla applications successfully. The trick is to ensure that the server recognizes the XUL file type and knows how to serve it properly. By default, most web servers serve files with such unrecognized extensions as text/plain. By adding the type application/vnd.mozilla.xul+xml to your server's configuration, you can make sure that the server matches the file extension and sends this MIME type in the HTTP header to the browser. To serve up static XUL pages from your web server, you need to add this line to your mime.types file if it hasn't been added already:
application/vnd.mozilla.xul+xml <TAB> xul
This is how you can configure Apache MIME types to serve static XUL pages. Note that the mime.types file requires that you separate the type from the suffix. The format is:
mime type <tab> extension.
After the type is added to the server, the browser recognizes this header as an XUL file and parses, renders, and creates the appropriate DOM. If your server isn't configured to recognize this MIME type, then users see the contents of your file as source only -- a plain text complete with all the formatting.
Now that your web server is configured correctly, you can add a sample XUL file (such as the file in Example 12-3) to your web site to make sure things are running properly. You should name the file remote.xul and save it in your web site's root directory for testing.
You can now view this window by launching it as a chrome file from Mozilla as follows:
./mozilla -chrome http://my.domain/remote.xul
Or you can also load it up by simply entering the URL in your browser location bar as follows::
http://my.domain/remote.xul