166946 - lockpref function not recognized in prefs.js or all.js, etc.

Status: RESOLVED INVALID

(Core :: Preferences: Backend, defect)

Description

[Douglas Abbink]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; (R1 1.1); .NET CLR 1.0.3705)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826

In Mozilla 0.9.6 and Netscape 6.2, the use of lockpref or PrefConfig.lockPref 
worked to lock out the user's ability to modify a setting such as a proxy 
server.

Now, in Mozilla 1.1 and Netscape 7.0, when the browser starts up, a dialog box 
pops up saying the lockpref command is "not a function" or "not defined."


Reproducible: Always

Steps to Reproduce:
1. put the lockpref() or PrefConfig.lockPref() function into prefs.js or all.js
2. start browser
3.

Actual Results:  
Dialog box message with error.  Desired Locked preferance is not locked or 
even set.

Expected Results:  
Started normally and, in prefs window, had indicated preference set and locked 
for changes.

Comment 1

[Brian Nesse (gone)]

This support was intentionally removed.

The preference locking support was moved to the AutoConfig module in advance of
the planned movement away from a JavaScript oriented preferences back-end.
lockpref is now a supported function only in the AutoConfig JavaScript context,
which processes the netscape.cfg and autoconfig.jsc (server based) files.

Comment 2

[Douglas Abbink]

From the comment made at the closing of this bug, it appears that this is not 
a “bug” in the traditional sense.  This support was removed/changed 
intentionally.  So, I am going to make the case for getting this functionality 
fully supported ASAP.  My comments will primarily focus on locking of proxy 
settings.

1. Why does locking of preferences need to be completed/fully supported?

Many companies/schools/etc. desire the ability to control how their network 
traffic is directed.  This is often accomplished for HTTP traffic by the use 
of proxy servers.  Although it is possible to limit access to the Internet 
using firewall rules and other measures, and doing so might make changing a 
Network Admin’s preset preferences futile, an ignorant or devious user can 
cause large support headaches for an IT staff when able to make changes to 
such settings.

Thus, many IT groups use the ability of the browsers and OSs to prevent users 
from changing these vital settings.

2. Does presetting the preferences through .js files or the Netscape CCK solve 
this problem?

Partially.  By manually inserting lines into the .js files or, for Netscape, 
using the Netscape CCK, the preferences can be preset, but they cannot be 
locked from user changes.  Thus any user with moderate knowledge can bypass 
the desired setup.  

It used to be possible (Netscape 4.x-6.2) to lock these preferences in the 
same way as presetting them is done now.

3. Do other web browsers offer such abilities?

Yes.  

As mentioned above, earlier versions of Netscape offered this ability through 
the *.js files and the lockPref() command.  

Microsoft Internet Explorer 4.x and above accomplishes this through removing 
the “connections” tab in the Internet Settings properties page.  This is done 
through a registry setting either manually or through the IEAK available from 
MS.

Opera accomplishes this through a setting in the Opera.ini (version 5) or 
Opera6.ini (version6).

And these are just examples from the Top 3 browsers.

4. Couldn’t a savvy or knowledgeable user just remove these locks from areas 
such as prefs.js, or registry, etc.?

Yes and no.  Yes it is possible for a knowledgeable user to undo all the 
protections put in place by an Admin, but only if the Admin does not take the 
additional step of locking down the proper areas/files in the OS.



In conclusion, these are only a few, quick thoughts on why the removal of the 
lockPrefs() support in the current browser releases is a hole that needs to be 
filled and how current solutions, such as the Netscape CCK do not fully solve 
the problem.  Because these browsers do not support this feature, I and many 
others will have no choice but to actively prevent these versions from being 
installed in our environments due to lack of Administrative control.

Comment 3

[Brian Nesse (gone)]

Douglas, I was going to try and address your points individually, but it just
didn't make sense that way. So let me paraphrase...

4.x style preference locking is fully supported in mozilla. For a number of
reasons, speed and security being the two major reasons, we decided it would be
good to get away from the JavaScript oriented preferences mechanism we have been
using for years.

In order to continue supporting this "enterprise" functionality in a "more
controlled" (safer) environment, we moved that functionality into a separate
module (the AutoConfig module).

With this implementation we have simply limited the number of places where
preferences can be locked. Preferences can no longer be locked in all.js or
prefs.js, they must be locked in one of two files that, by default, are named
netscape.cfg (a local, hashed, file) or in autoconfig.jsc (a server based file.)
This actually addresses your fourth point somewhat because neither of these
files is easily accessible to the user.

The code which activates the use of the configuration (.cfg) and subsequently
the autoconfig.jsc file is enabled by setting the "general.config.filename"
preference in all.js.

What you are really looking for, I believe, is the ability to create/modify the
netscape.cfg file. There is already a bug in the the database (bug 103545) which
relates to this need (though in a much larger scope.)

Comment 4

[Douglas Abbink]

I recognize that this functionality still exists and was only moved not 
removed.

It does seem apparent from bug 103545 and comments here that what I desire is 
the ability to generate a netscape.cfg file.  

As there does not currently seem to be a way to generate this file, is the 
file format documented/available so that such a file can be put together 
manually (even if it is a binary file)?

Comment 5

[Brian Nesse (gone)]

The group within Netscape that was originally tasked with creating the tool you
desire was effectively disbanded through a series of layoffs/reorgs.

Everything that one needs to know about the config file can be found in the
function "openAndEvaluateJSFile" in the file nsReadConfig.cpp which can be found
in mozilla/extensions/pref/autoconfig/src/.

Comment 6

[Douglas Abbink]

Ok, I have now worked out (with help from Brian Nesse) how to use the
lockprefs directive.  

Follow steps below:

Assume install directory is "c:\program files\netscape" on a windows
machine.

1. Create an ASCII file (for example lockpref.js) and put in the standard
lockpref commands you wish.  For example:

lockPref("network.proxy.type", 1);
lockPref("network.proxy.http", "internalproxy.mycompany.com");
lockPref("network.proxy.http_port", 8088);

IMPORTANT NOTE: the first line of this ASCII file should be a comment line
(double forward slash, "//")

2. This file must now be converted to a netscape.cfg file.  This file is
encoded with a simple byte shift encoding.  It is shifted 13 bytes positive
on every byte.  The easiest way to do this is to find a program that will
shift the bytes of the entire file for you.  For a GUI Win32 app or
commandline Linux app that does this see http://www.dabbink.com (both
whipped up by me).  You will find them under the link for "Byte Shifter"

3. Once converted put the file in your "C:\Program Files\Netscape\Netscape"
directory.

4. In C:\Program Files\Netscape\Netscape\defaults\pref\all.js, add the line
pref("general.config.filename", "netscape.cfg"); to the end of the file.


These steps should lock the selected prefs.

I think that is all.  Hope this helps everyone out there with this problem.