In-Cider Knowledge: ADM XPI For Firefox

Group Policy Extension for Firefox 1.x

Mon, 19 Jun 2006 23:19:57 GMT

Well, after that long weekend article about Firefox, I thought it was about time to put my own money where my motuh is and get back to the stuff that you were reading this blog for in the first place.

This is to announce another test version of my Group Policy extension for Firefox.

Find it here: http://homepages.ed.ac.uk/mcs/GPOforFirefox.zip

Major differences on previous versions is this one works in 1.5.x (oi, who was that saying "FINALLY!"...). I've also renamed the extension from the slightly acronym-crazed ADM XPI to Group Policy Extension for Firefox. Thirdly, I've totally changed the locations in the registry that Administrative Templates are read from. Its now use these registry locations: HKLM\Software\Policies\ADM\Firefox, HKLM\Software\Policies\ADM\Firefox\Locked, and the same place under HKCU. Email me at "mark dot sammons at ed.ac.uk" for more info if needed.

Only weird thing I've found with this release is if you copy the XPI file to the extensions folder in Program Files\Mozilla Firefox, it will try to keep installing itself. Best way to install is to close Firefox and then double click on the XPI file.

Consider this still a technology proof of concept, but can be used if you are repackaging Firefox to an MSI.

I'd still love to find the time to really pull Firefox apart and see if I can write this in as a patch, especially since the code is actually quite easy.

Firefox ADM XPI Test 2 Release

Thu, 08 Dec 2005 22:28:42 GMT

As the subject says.

This version is a further test version of this extension for Firefox 1.5 only. The functionality has now been brought up to the same level as the ADM XPI for Thunderbird. Full features:

every preference settable - just use same registry name as preference you are trying to set
4 levels of granularity of control - preference set on a per user config, preference set on a per computer config, preference set and locked on a per user config & preference set and locked on a per computer config - override in that order (eg. if you set browser.startup.homepage to http://www.ed.ac.uk on a per computer config, but then if browser.startup.homepage is set and locked to http://news.bbc.co.uk on a per user config, then the resulting value will be http://news.bbc.co.uk and locked for that user)
ability to use environment variable in settings, and special variable %homesharehomepath% for %homeshare%%homepath% environment
settings on per-session basis. So, for example, if you remotely attached to a machine and changed the browser.startup.homepage value in the registry, the home page will be changed the next time the user launches Firefox 1.5.

More later! Here's the link to the extension: http://homepages.ed.ac.uk/mcs/admxpi_test2.zip (server is sometimes flakey at the moment, so if rejects you or says cannot find the page, just refresh)

Go!

Fri, 09 Sep 2005 16:42:21 GMT

Beta 1 of Firefox 1.5 was released today so some extra tidbits on ADM XPI for Firefox 1.5

To install:

- copy the admxpi.xpi to C:\Program Files\Mozilla Firefox\extensions

- Run Firefox 1.5. It will say there is an untrusted extension that need to be installed. Click Yes (I'll make the XPI installation smoother, honest!).

That's it!

To test its working:

- Open up regedit and go to "HKEY_LOCAL_MACHINE\Software\Policies"

- Right click on the "Policies" key and New...Key. Name the key "Firefox.XPI"

- Right click on the newly created "Firefox.XPI" key and New...Key. Name the key "Locked"

- Right click on the newly created "Locked" key and New...String Value. Name the string value "browser.startup.homepage". Give it a value of http://news.bbc.co.uk (or your own URL).

- Load Firefox 1.5

- Click on the Home icon. It should go to the address above.

- Go to Tools, Options menu. In the General tab, the homepage icon should be set to the address above and should be greyed out and uneditable.

Some other tidbits:

- At the moment, this supports String values only in the registry. As such, when doing Admin templates, do not use the NUMERIC keyword, even when putting in numbers (eg do not use VALUEON NUMERIC 12, just use VALUEON 12).

- When manually editing the registry to input values, do not use DWORD or Binary values. Numbers should just be put in Strings values.

- Values: Boolean values are 1 for True and 0 for False. Numeric and String are just as you want them to be in Firefox.

More later.

Beyond the Tease

Wed, 07 Sep 2005 22:52:19 GMT

OK, so the last post was a bit of a tease on something I have been working on. I had hoped to post the follow-up sooner, but things have been a bit bad and I'm very disillusioned after the last few days at work. By the way, any recruiters from Google, Microsoft, IBM, Yahoo, etc watching, I'm the man you're after!!

Anyway, what is this thing I mentioned?

Back in May I had a crazed weekend of trying to write an extension from scratch. And it worked great, but I never really took it anywhere. About two months ago, I was emailed by Michael Kaply. He works at IBM on Mozilla and emailed me because he was starting up the Client Customisation Kit wizard project (http://www.mozilla.org/projects/cck/firefox/). This got me thinking about how I would use an extension for doing the Active Directory/ZenWorks stuff. Thanks to a few gems of guidance from Michael, I quickly managed to get somewhere.

The result: ADM XPI for Firefox 1.5. And I'm a bit chuffed with it!

Feature wise, I looked at FirefoxADM, the feedback I had on FirefoxADM, the feedback on Bugzilla for the Group Policy enhancement bug (https://bugzilla.mozilla.org/show_bug.cgi?id=267888) and some intuition as an admin.

Feature wise, let's start with the Admin Template. Note, there isn't a perscribed one! I'll certainly try and do a few and maybe even a wizard thing that creates them, but that a secondary project. Here's an example:

CLASS USER

CATEGORY "Mozilla Firefox XPI Settings"

KEYNAME "Software\Policies\Firefox.XPI"

POLICY "General Settings"
PART "Homepage" EDITTEXT REQUIRED
VALUENAME browser.startup.homepage
END PART
END POLICY

END CATEGORY

This lets you set the homepage as an per-user overwritable preference.

Here's another example:

CLASS MACHINE

CATEGORY "Mozilla Firefox XPI Settings"

KEYNAME "Software\Policies\Firefox.XPI\Locked"

POLICY "General Settings"
PART "Homepage" EDITTEXT REQUIRED
VALUENAME browser.startup.homepage
END PART
END POLICY

END CATEGORY

This let's you set the homepage as a locked per-computer preference.

ADM XPI only really cares about 3 of the lines in those example above:

CLASS USER - per user setting, CLASS MACHINE - per machine setting

KEYNAME "Software\Policies\Firefox.XPI" - default, overwritable preference, KEYNAME "Software\Policies\Firefox.XPI\Locked" - locked preference

VALUENAME - whatever valuename is set to, is the preference in Firefox it is setting.

This gives you 4 different ways to set any preference in Firefox. However, it goes further than this. If you find in the AD that you have more than 1 of these ways set for any preferences, the system has a fixed hierarchy:

Per User Preference

Per Machine Preference

Per User Locked Preference

Per Machine Locked Preference

So, take that example of the 2 admin templates above that both set the homepage. Let's say both are set to different pages and applied to the same machine. The Per Computer Locked Setting will "win" because of the preference hierarchy I have defined in ADM XPI (by the way, a lot of people get confused about user settings applied to computers - this of course all depends on whether you have loopback enabled, but let's not go into that murky area at the moment!).

Why this whole area is really good for Firefox 1.5, is that (a) the extension deployment is a lot cleaner and (b) Firefox 1.5 contains the code necessary to do this extension!

Another great thing that comes out of this is that there are no logon or startup scripts or anything. As long as the extension is installed, and this can be installed on the machine so it cannot be removed, it applies the settings when Firefox is launched. This leads onto another fiendish thing - this means you can live update machines remotely. As long as you can remotely connect to a machine's registry, you can put in settings that will be there immediately on the next run of Firefox, and the user doesn't have to log out or anything!

Please test and give feedback to mark(dot)sammons(at)ed.ac.uk: http://homepages.ed.ac.uk/mcs/admxpi_test1.zip.

Thanks

ADM XPI for Firefox 1.5

Fri, 02 Sep 2005 01:03:20 GMT

This may still be a while away (latest roadmap points to a release date deep in November...OUCH!), but I have been contemplating certain things regards the next version of Firefox, 1.5 (codenamed Deer Park).

Most significantly, I noticed features-wise, it offered a couple of tantalising tidbits for extension developers. As such, over the last weekend and few days I have been working on something for it. Back in mid-May, I spent a weekend messing about with extensions and the like and came up with a very rough extension for Firefox. Well, for Firefox 1.5, I went back to that, rewrote it properly, sorted out the coding and also added in a couple of special bits. I now have a pretty cool working version, so I'm going to start releasing test versions in the next couple of days.

What is it?

Makes Firefox 1.5 fully Active Directory configurable
Install the extension onto any install of Firefox (be it a Mozilla MSI, custom MSI or even manual install) and that's all the setting up you need - extension installation code in Firefox 1.5 allows scriptable installation of extensions on remote machines
Just need to write an Admin Template where the VALUENAMEs are the same as the pref's inside Firefox, and it will set those values
4 levels of granularity: User set default, computer set default, user locked setting, computer locked setting - override each other in that order as well
Live updating. Changing the pref on a machine in the registry and then restarting Firefox will immediately cause that setting to be effected.

I am going to test it and then in the next couple of days start to release test versions. I should point out that this does not mean FirefoxADM will end. There are features in FirefoxADM that go way beyond the prefs level of Firefox and so, it will still be needed by many who use it.

I've also been talking to Michael Kaply from IBM who recently resurrected the Client Customisation Kit project for Firefox. I'm hoping that maybe this tool and the CCK can come together to add extra levels of customisability for people who need it.

Anyway, more details in the next post.

Cannot. Stop. Posting...

Sun, 15 May 2005 22:58:54 GMT

OK, this is the last one for today. It wont make any sense unless you have read from way down there at "Adventures in XPI - Part 1"!

If this all works, then there is scope to do the following in that PrefSet function:

function PrefSet(prefName,setType)
{

try {
  var FirefoxSetter = reg.getRegistryEntry(2,"Software\\Policies\\Firefox\\Default",prefName);
  if(setType=="char")
  {
   prefs.setCharPref(prefName, FirefoxSetter);

  }
  if(setType=="int")
  {
   prefs.setIntPref(prefName, FirefoxSetter);
  }
  if(setType=="bool")
  {
   prefs.setBoolPref(prefName, FirefoxSetter);
  }
  } catch (ex) {}

try {
  var FirefoxSetter = reg.getRegistryEntry(3,"Software\\Policies\\Firefox\\Default",prefName);
  if(setType=="char")
  {
   prefs.setCharPref(prefName, FirefoxSetter);
  }
  if(setType=="int")
  {
   prefs.setIntPref(prefName, FirefoxSetter);
  }
  if(setType=="bool")
  {
   prefs.setBoolPref(prefName, FirefoxSetter);
  }
  } catch (ex) {}

try {
  var FirefoxSetter = reg.getRegistryEntry(2,"Software\\Policies\\Firefox\\Locked",prefName);
  if(setType=="char")
  {
   prefs.lockPref(prefName);
   prefs.setCharPref(prefName, FirefoxSetter);

  }
  if(setType=="int")
  {
   prefs.lockPref(prefName);
   prefs.setIntPref(prefName, FirefoxSetter);
  }
  if(setType=="bool")
  {
   prefs.lockPref(prefName);
   prefs.setBoolPref(prefName, FirefoxSetter);
  }
  } catch (ex) {}

try {
  var FirefoxSetter = reg.getRegistryEntry(3,"Software\\Policies\\Firefox\\Locked",prefName);
  if(setType=="char")
  {
   prefs.lockPref(prefName);
   prefs.setCharPref(prefName, FirefoxSetter);
  }
  if(setType=="int")
  {
   prefs.lockPref(prefName);
   prefs.setIntPref(prefName, FirefoxSetter);
  }
  if(setType=="bool")
  {
   prefs.lockPref(prefName);
   prefs.setBoolPref(prefName, FirefoxSetter);
  }
  } catch (ex) {}
}

...as in, for any setting, try in this order:

User - Default
Computer - Default
User - Locked
Computer - Locked

This is very untested and I'll look into it tomorrow as well as seeing if I can fix a couple of problems with FirefoxADM/ADM for Firefox. There's a crap issue with upgrades and an issue with the new cookie handler (I'm actually not sure how, but a then statement has gone a tad AWOL). Unless disaster, I'll get that out by the end of play tomorrow.

Its likely that ADM For Firefox 1.0 wont be released until about the start of June because I am going to get a much-needed break away from everything and computers for a week and a half. So need to get things as settled as possible by Wednesday.

But until tomorrow, adieu!

And to lock...

Sun, 15 May 2005 22:28:08 GMT

Just figured it out! Here's how you lock the settings:

function PrefSet(prefName,setType)

{

try {

var FirefoxSetter = reg.getRegistryEntry(2,"Software\\Policies\\Firefox.XPI",prefName);

if(setType=="char")

{

prefs.lockPref(prefName);

prefs.setCharPref(prefName, FirefoxSetter);

}

if(setType=="int")

{

prefs.lockPref(prefName);

prefs.setIntPref(prefName, FirefoxSetter);

}

if(setType=="bool")

{

prefs.lockPref(prefName);

prefs.setBoolPref(prefName, FirefoxSetter);

}

} catch (ex) {}

try {

var FirefoxSetter = reg.getRegistryEntry(3,"Software\\Policies\\Firefox.XPI",prefName);

if(setType=="char")

{

prefs.lockPref(prefName);

prefs.setCharPref(prefName, FirefoxSetter);

}

if(setType=="int")

{

prefs.lockPref(prefName);

prefs.setIntPref(prefName, FirefoxSetter);

}

if(setType=="bool")

{

prefs.lockPref(prefName);

prefs.setBoolPref(prefName, FirefoxSetter);

}

} catch (ex) {}

}

Damn, its looking a whole lot more powerful than FirefoxADM, already! That wasn't meant to happen.

By the way, the name of this is, as the topic gives away "ADM XPI For Firefox". Hope someone can find a use for it...

Adventures in XPI - Prologue

Sun, 15 May 2005 19:12:00 GMT

OK, I've uploaded those. Questions and criticisms to mark(dot)sammons(at)ed.ac.uk.

I should point out that I am very new to this myself so may have made a few massive mistake in it all and it is very much a work in progress that I have only experimented with, and SHOULD NOT BE DEPLOYED to a production environment.

Oh, and as ever, this work is Public Domain.

Get it here:

http://homepages.ed.ac.uk/mcs/ADMXPI_0.1.zip
(the main all-encompassing one!)

and, the files I used in experimenting:

http://homepages.ed.ac.uk/mcs/ADMXPI_Experiments.zip

Thanks...

Adventures in XPI - Part 5

Sun, 15 May 2005 19:00:09 GMT

You write your own ADM template for applying settings. Here's the example:

CLASS USER

CATEGORY "Mozilla Firefox XPI Settings"

KEYNAME "Software\Policies\Firefox.XPI"

POLICY "General Settings"
PART "Homepage" EDITTEXT REQUIRED
VALUENAME browser.startup.homepage
END PART
END POLICY

END CATEGORY

CLASS MACHINE

CATEGORY "Mozilla Firefox XPI Settings"

KEYNAME "Software\Policies\Firefox.XPI"

POLICY "General Settings"
PART "Homepage" EDITTEXT REQUIRED
VALUENAME browser.startup.homepage
END PART
END POLICY

END CATEGORY

Everything is identical between the machine and user part, apart from the CLASS type, so you can easily C&P between the two.

But if I wanted this to be completely extensible, what would I need to do? Either scan the registry key and then apply whatever is in there (the preferable solution - and one I am trying to achieve). Or...

http://homepages.ed.ac.uk/mcs/admxpi.txt

(BTW, purely coincidentally, that only looks like a text file in Firefox, as IE tries to render it!)

Adventures in XPI - Part 4

Sun, 15 May 2005 18:40:41 GMT

At this point, I decided to do things a little differently and not go down the whole FirefoxADM route.

That owes a lot to the translation stage in the code and I wanted this to be lighter. As such, I decided to make everything a whole lot more generic.

What this would entail is making the entry in the registry exactly the same as the final pref. As such, if you want to write a template to change a certain pref, just code that into the ADM template, not have to write the translator in the code.

The XUL became this:

<?xml version="1.0"?>

PrefSet("browser.startup.homepage","char");

try {
  var FirefoxSetter = reg.getRegistryEntry(3,"Software\\Policies\\Firefox.XPI",prefName);
  if(setType=="char")
  {
   prefs.setCharPref(prefName, FirefoxSetter);
  }
  if(setType=="int")
  {
   prefs.setIntPref(prefName, FirefoxSetter);
  }
  if(setType=="bool")
  {
   prefs.setBoolPref(prefName, FirefoxSetter);
  }
  } catch (ex) {}
}

</script>

</overlay>

So, same interfaces (but note, now ADMXPI branded!). However, the functionality becomes a call of:

PrefSet("browser.startup.homepage","char");

which passes the setting name and setting type ("char", "int or "bool" for Char, Integer or Boolean) to the function PrefSet. PrefSet tries to first read from the Current User registry for the preference name from Software\Policies\Firefox.XPI and set accordingly, and then from the Local Machine registry. This gives a notion of Machine policies override User policies. Maybe right, maybe wrong, we can come back to that.

And this works (on my local machine, no AD testing yet!).

So...

take that one major step further and implement all the settings from FirefoxADM Login...

<?xml version="1.0"?>

PrefSet("accessibility.browsewithcaret","bool");
PrefSet("accessibility.typeaheadfind","bool");
PrefSet("browser.cache.disk.capacity","int");
PrefSet("browser.cache.disk.parent_directory","char");
PrefSet("browser.download.defaultFolder","char");
PrefSet("browser.download.dir","char");
PrefSet("browser.enable_automatic_image_resizing","bool");
PrefSet("browser.shell.checkDefaultBrowser","bool");
PrefSet("browser.startup.homepage","char");
PrefSet("network.proxy.autoconfig_url","char");
PrefSet("network.proxy.ftp","char");
PrefSet("network.proxy.ftp_port","int");
PrefSet("network.proxy.gopher","char");
PrefSet("network.proxy.gopher_port","int");
PrefSet("network.proxy.http","char");
PrefSet("network.proxy.http_port","int");
PrefSet("network.proxy.no_proxies_on","char");
PrefSet("network.proxy.socks","char");
PrefSet("network.proxy.socks_port","int");
PrefSet("network.proxy.socks_version","int");
PrefSet("network.proxy.ssl","char");
PrefSet("network.proxy.ssl_port","int");
PrefSet("network.proxy.type","int");
PrefSet("xpinstall.dialog.confirm","char");
PrefSet("xpinstall.dialog.progress.chrome","char");
PrefSet("xpinstall.dialog.progress.skin","char");
PrefSet("xpinstall.dialog.progress.type.chrome","char");
PrefSet("xpinstall.dialog.progress.type.skin","char");
PrefSet("xpinstall.enabled","bool");

</script>

</overlay>

Which of course, leads me to...

Adventures in XPI - Part 3

Sun, 15 May 2005 18:20:05 GMT

Coding to the interface that Firefox gives extension writers should be easy, right? After all, there's endless amounts of documentation and if that fails, there's that wonderful thing called the Internet to look things up on. Yeah, sure!

Its been a living nightmare! OK, maybe not that bad, but still: Not fun.

I managed to find the methods of setting Prefs pretty easily, but drawing settings from the registry almost killed the whole idea. I've spent two nights this week taking different angle and different ways of attacking this. Nothing worked and you are literally shooting in the dark. There seems to be this feeling that if you have an open source product, you don't need to write documentation! But I've leave that opinion there, so the terms "pot" "kettle" and "black" don't get sent to me...

Then, I found this: http://xl8.net/blog/archive/2004/08/09/1002.aspx

The Holy Grail.

I was then able to put this XUL file together:

<?xml version="1.0"?>

try {
var FirefoxHomepage = reg.getRegistryEntry(3,"Software\\Policies\\Firefox","FirefoxHomepage");
prefs.setCharPref("browser.startup.homepage", FirefoxHomepage);
} catch (ex) {}

</script>

</overlay>

Notice it still owes a lot to the HelloWorld example!

Everything in it is still from the HelloWorld except for the script section. In that it opens up a couple of interfaces to use - the ones I've been hunting for so endlessly over the past few days, and then wrapped in a "try, catch" error-handler, reads from the same registry entries as FirefoxADM and sets a String pref for browser.startup.homepage.

And it works! So what next?

Adventures in XPI - Part 2

Sun, 15 May 2005 17:43:49 GMT

When you start off with XPIs, things get very confusing very quickly. The reason? Take this explanation of a XPI:

"A XPI is a ZIP file containing a chrome folder and a install.rdf file. The RDF file contains XML which describes the installation of the package. Inside the chrome folder is a JAR file, which is a ZIP file. Inside the JAR file, there is a content folder which contains a content.rdf file which is an XML file and a XUL file. The XUL file contains XML which actually does the workhorse behaviour."

Phew, the what does what now? And jeez, too many X's!

For the above reasons and the fact I am just getting to grips with all this, this ain't going to be a tutorial! Please go to XUL Planet and the Hello World example (http://www.orablogs.com/duffblog/archives/000536.html). See this more of a description of my experiences!

I started off with that Hello World example and started to basically alter it from the inside out. My first Technology Test was done by just changing the XUL file. It would become obvious that virtually all of my changes would be within this file.

It was surprising simple to get to grips with, especially once I discovered how to embed script into the XUL file using the <script type="application\x-javascript"> XML tag.

The next thing to decide was a plan for the general algorightm. It seemed as we were still performing the same sort of actions as FirefoxADM, this algorithm can be carried over.

As such, we start with registry keys, translate them and then plug it into Firefox.

The only problem is, whereas with FirefoxADM, this was done by altering Firefox's input files, by the time this XPI executes, we were inside Firefox and couldn't do it the same way. I had to plug the settings in via Firefox's API.

Sounds easy, eh?!

Adventures in XPI - Part 1

Sun, 15 May 2005 16:02:58 GMT

I've been wondering about the possibilities of XPIs and "ADM for Firefox" for a while now. Last week, I finally sat down and had a play.

But why?

Well, basically, its one level less of abstraction between ADM For Firefox and Firefox. At the moment, the scripts manipulate the prefs before they are pushed into Firefox. The aim of doing this experimenting is to see if I can manipulate the preferences in Firefox. However, ultimately, unless this goes all too well, I don't mean for this to be a replacement of ADM For Firefox, so on top of the reasons above, I'm going it because its fun to try things out!

Oh well, let's start...