Closed
Bug 166946
Opened 22 years ago
Closed 22 years ago
lockpref function not recognized in prefs.js or all.js, etc.
Categories
(Core :: Preferences: Backend, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: Douglas, Assigned: bnesse)
Details
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.
Assignee | ||
Comment 1•22 years ago
|
||
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.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 2•22 years ago
|
||
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.
Assignee | ||
Comment 3•22 years ago
|
||
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.)
Reporter | ||
Comment 4•22 years ago
|
||
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)?
Assignee | ||
Comment 5•22 years ago
|
||
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/.
Reporter | ||
Comment 6•22 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•