 |
|
This section details the basic processes required to make the Mozilla Firefox web browser use a central configuration to allow system administrators to control settings on behalf of the user.
Mozilla Firefox is rapidly becoming a very popular browser in the community. However, for the corporate user, Mozilla Fire presents some initial and interesting problems. The main concern for system administrators wishing to deploy Mozilla Firefox across a corporate network, is controlling settings.
This article covers the implementation of a central configuration for Mozilla Firefox. This configuration is applied every time (or at pre-defined intervals) that Mozilla Firefox is started or is operating. It took me a while to search the Internet to gather this information from many sources. I have written this article, because at the time of writing, I had been unable to find a single, definitive source of this information, and I thought I would share it with you.
The basic configuration principle is similar to the Netscape browsers, but is slightly different in several respects. Although I am a Windows system administrator, and this article covers using Mozilla Firefox within this environment, it should be possible to take this information and adapt it to your preferred Mozilla Firefox platform.
I have placed this section near the top of this article mainly to assist administrators already familiar with this process as an 'Quick Reference'. And for those that have already read fully this article, or those of you who are just 'brilliant' people. I would suggest that you read the rest of this article first, unless you are familiar with the process.
Before Firefox can use a central configuration, it must be compiled with this feature enabled. To achieve this, either compile your own edition, or ensure that the copy you have has had this feature enabled. You can check for feature being enabled in your installation by using the following method:
about:buildconfig
If you require the use of LDAP in your central configuration scripts to aid identification of systems and users, then this needs to be specified at compile time too, in the same section as 'pref'. The above example clearly shows that LDAP is NOT enabled for this compile and therefore can not be used by this version.
Once you have an installed copy of Firefox that you are going to use that meets your requirements, you need to edit the all.js file to inform Firefox to use a configuration file to locate your central settings. Once this file has been 'patched', you need to deploy it after installing Firefox on each platform that you wish to control settings for.
In addition, you might
like to alter the file permissions to prevent users from altering the contents
of this file. If the file permissions were set such that everyone could
read, and not even administrators can change, then any re-installs or upgrades
of Firefox will not over-write the file either.
You can edit this file with any normal text editor, such as NotePad. The file is normally located in the 'greprefs' directory, directly bellow the directory that Firefox was installed to. Firefox normally installs to '%ProgramFiles%\Mozilla Firefox' on windows systems.
Carefully search the file for the following two preferences. They may or may not be present (if not create them) and they may or may not be together (if not bring them together).
general.config.obscure_value
general.config.filename
An example of the lines you are looking for, one of the lines you are looking for is marked with the red arrow in the image below:
In this case, only the first line was located in 'all.js', and it is the correct value. Edit the file to correct/add the following configuration lines:
lockPref("general.config.obscure_value", 13); // for MCD .cfg files
lockPref("general.config.filename", "firefox.cfg");
If you wish to use a different name for your configuration file, other than 'firefox.cfg', then alter the second string on the second line to match what you require. The name can be almost anything, but 'firefox.cdf' looks and feels about right. Ensure case is correct or things will not work!
The preference type is changed from 'pref' to 'lockPref'. This prevents the user from ever being able to change the file if they were to discover in a current or future preferences panel.
An example of a patched file is shown below:
So what do these to parameters do?
Well the first parameter: 'general.config.obscure_value', specifies what encoding has been used on the file. By default, Firefox uses a encoding called ROT13. Netscape used ROT7. If you do not wish to use an encoded .cfg file, then set this to 0 (zero). There are many tools on the web that can provide this encode and decode for the .cfg text file. If you do not set this parameter to match your .cfg file encoding, then it will not read the file correctly. A Perl script to ROT and unROT can be found in the Further Reading section.
Set
the 'general.config.obscure_value' value to zero, so you do not need to
encode/decode the file while testing the system. Once operational, it can
then be encoded to prevent viewing by most users. This can speed up
development and testing.
The second parameter: 'general.config.filename', specifies the name of the configuration file that Firefox will open to link to your central configuration. This configuration file is located with in the same executable directory as Firefox itself.
You may
not supply any path information for this variable, nor can you provide Firefox
or enviromental variables (such as %WinDir%). You may only specify the
filename and the file must exist the the same directory as the main Firefox
executable.
I would also suggest that the configuration file name is kept to the original 8.3 naming convention.
The configuration file is also created and edited with a normal text editor, such as NotePad. Once created, it needs to be save with the same name as you specified in the 'all.js' file and reside in the same directory as the main Firefox executable.
An example configuration file is shown below:
The format of this file is quite simple and described in detail below:
Line 1 contains the text: 'Content-type: application/x-javascript-cong', advises Firefox of the content type for this file. If it is not included, then Firefox will load, but will not process the file contents. Basically it is telling Firefox that the content of this file is and application configuration file coded using JavaScript.
Line 3 contains the locked parameter that specifies the location of your central configuration script. It is a URL to the file that contains your central configuration script. Any URL can be specified in the URL that can specified normally in the address bar of Firefox. Change this URL to match exactly where your configuration file. Ensure that your fully qualified domain name (FQDN), path and file name are all correct.
Test
by placing your URL in the address bar of Firefox and fetching the page.
If you do not wish to hold your configuration file on a web/intranet/internet server, then you may specify a file path using a format similar to the example shown below:
file://\\servername\share\path\configfile.js
What ever method you use, test it to make sure that Firefox can fetch the file correctly.
Line 4 locks Firefox into sending (true) or not sending (false) the users email address with the request for the central configuration. If set to 'true', the configured users' email address in Firefox is sent along with the request, if set to 'false', then it is not sent. Useful only with page request types that support this information feed, such as 'http', but not 'ftp' or 'file'. Each user must have a configured email address ID in Firefox for this work work via 'http'.
As
an alternative, and if your edition of Firefox has LDAP enabled at compile time
(See Firefox Extensions), then you can also use
LDAP to resolve certain additional user information. If not, then you will
be restricted in varying the central configuration by user/system.
The
central configuration is fetched from the location specified in the .cfg file
and is executed at the system that made the request in the context of the user
who started Firefox. Bear this in mind when making decisions based on the
user or system in your configurations.
Now that you have configured Firefox to fetch a central configuration, only the final file needs to be created. This is where the actual file contents become specific to your setup. The central configuration file can be as simple or as complex as you require. The file can just configure the setup the same for every user, or it can make decisions based upon the user invoking Firefox and/or the system and network that Firefox is starting up into.
It is beyond the scope of this document to get into the programming of JavaScript. There are plenty of web site out there that can help you here. The other information detail that is beyond the scope of this document, is the list of Preferences that can be configured. The list is extensive and becomes larger with each new release of Firefox and with each new Extension added.
You can view the current configuration of Firefox by browsing to the following address:
about:config
An sample section of configuration is shown below:
As you can see from the scroll bar on the right, what is shown is a very small proportion of the settings available to Firefox. Most of the settings actually control the Gecko renderer built into Firefox, rather than Firefox itself.
For a excellent Extension for Firefox to allow you to gain some insight into the nature of each setting, I would suggest installing the Preferential! extension, see Further Reading below. Also as Firefox is derived from Netscape Communicator, so many of the settings for Netscape Communicator 4.5 (and later) are valid to Firefox.
There appear to be five basic commands to set a preference. Each has its own control over how the preferences are made available to Firefox and the user. These are detailed as:
Each of these has the same syntax for setting a preference, i.e.. pref("preference.name", "setting"). However, each of these limits how the preference is processed after loading. For example, lockPref prevents the preference from being changed by the user or over-ridden by a profile setting, defaultPref just sets a preference if it is not already set for the user. pref sets a preference, but it can be over-ridden by the user, either by options window, or using the 'about:config' address. You need to carefully decide have 'locked' a preference should be and if you are forcing the user to have this setting (eg your corporate firewall), or just want to offer the user a convenient start point that will get them started, such as a suggested list of popular links on the tool bar. But you don't mind if they change them later for something more useful.
Don't just force settings because you can. Setting the Firefox window to a mixture or purple and luminous green may have users hunting you down complaining of headaches and eye strain. Settings are there to protect the users, reduce support costs and make the whole experience reliable. Remember that this is your actual goal - happy users means a silent help desk phone!
The following short script for a central configuration, prevents Firefox from automatically installing updates to itself, extension updates continue as normal. It also prevents the user from using the 'Check Now' button in the options window.
lockPref("app.update.enabled", false); // Whether or not app updates are enabled.
lockPref("app.update.autoUpdateEnabled", false); // Whether or not background app updates.
Remember everyone who starts Firefox with a central configuration, must be able to fetch and read the files concerned. If not, Firefox will give on on the central configuration and continue as normal.
Fault finding your code will be tricky. Especially if you start to perform complex changes based on environment. You can a couple of environmental strings that may assist:
set NSPR_LOG_MODULES=MCD:5
set NSPR_LOG_FILE=~/log.txt
These, if set, will encourage the MCD module within Firelox to log some information, such as where and when configuration files are loaded. But don't expect an extensive diagnostic.
You can also use the pref API function: displayError(). However, there are reports that this command fails on current builds (1.0.4 is current at time of writing), but I have not tested this.
Any
links from this section, will open a fresh browser window. As these are
links to external, third party web sites, I offer them only as suggestions and can
not control their content or suitability of audience. Please accept my
apologies if you experience any unexpected issues with the external references I
have offered.
A Beta version of a administrator utility is available for download from here.
