Laird OnDemand: Enterprise Greasemonkey: Solving the Greasemonkey Script Versioning Problem

As I have covered in previous blogs, Greasemonkey is a powerful client-side tool for augmenting web sites or creating mashups. It consists of a Firefox plugin coupled with scripts that are written and installed to modify web pages as they return from a web server. When this tool is brought into the enterprise, IT must sort out issues like security and deployment. I covered security in my last post, and in this installment I will look at how IT can solve deployment and versioning issues for Greasemonkey scripts.

NOTE: this blog entry was originally posted August 19th, 2007 on my previous blogging system (dev2dev.bea.com). Comments on the old blog were not transferred.

This is part 5 of a series of blog entries on Greasemonkey mashups.

Blog 1: More Mashups: Using Greasemonkey to Weave New Features into Web Sites
Blog 2: Building a Greasemonkey Mashup Tutorial
Blog 3: Greasemonkey in the Enterprise: When is GM the Right Tool for IT?
Blog 4: Beware of Greasemonkey's Inverted Security Model
Blog 5: Solving the Greasemonkey Script Versioning Problem

The Need for Greasemonkey Script Deployment and Versioning

For this blog entry, imagine a web application in the enterprise with these characteristics:

It is a closed source packaged application, purchased from an external vendor.
It is used by a modest sized group of users, all of which are comfortable with computers and web browsing
There are a couple of missing features that dramatically hurt productivity
Those features can be easily woven into the application using a Greasemonkey script

Now, any one of those affected users could write the Greasemonkey script without involving IT. This script could then be passed around via email or a shared drive amongst colleagues. But there are few problems with this ad hoc approach to Greasemonkey:

As the script evolves, distribution and version management of the script will be difficult.
As new users are introduced to the web application, there is no formal process for getting them going with the script.
GM scripts are like .exe's - they can be host to malicious code. Unmanaged distribution could open the door for a hacker.
It is IT's mission to be the solution provider - IT should provide the Greasemonkey script.

Clearly, while IT can let the user community fend for themselves on this project, it would be far better for IT to own the solution. However, as always, unless IT can provide a solution quickly the users are apt to go with the ad hoc approach. Hopefully this blog entry will help you rapidly develop a sustainable solution, and add Greasemonkey to the list of official solutions for your enteprise.

Solving the Deployment and Versioning Issues for Greasemonkey Scripts

The rest of this blog entry discusses a solution that can provide manageability around Greasemonkey in the enterprise. It can solve the issues listed above, particularly the issues around deployment and versioning of a Greasemonkey script. This solution is by no means the only way to address these issues, but hopefully you will find it satisfies your requirements. The following describes characteristics of the solution:

It specifies a new landing page, or Gateway page, for the web application that users will hit before going into the app
This page can contain whatever you want, but it also has elements to help determine if the GM script is installed and up to date
The solution enforces the use of the Greasemonkey script (though it could be easily changed to make it only optional)
It provides version checking
It does not require any changes to the closed source web application
It is not foolproof - if the user avoids the Gateway page using a bookmark the enforcement is not run

The graphic below shows how the Gateway page fronts the web application to make sure the user has the proper Greasemonkey install. Ideally, the Gatekeeper page would be integrated into the web application's login page so a user could not bookmark their way around the enforcement. If the browser is not properly configured, the Gateway page obscures the Enter the Site button until the problem is corrected. Also note that the proper version of the Greasemonkey script should be located on a web server defined and managed by IT so the Gatekeeper page can direct the user to it if necessary.

Versioning is implemented by including a div element on the Gateway page with the version number of the script that users should be using.

<div id="gm-script-ver-415" />

The Greasemonkey script looks for the div tag with it's version number. If it does not find it, it will not make the Enter the Site link visible.

The Solution Step by Step

Check 1: Is the browser Firefox? If not, a message discloses the problem.

Check 2: Is Greasemonkey and the script installed? If not, the page offers the download links for both.

Check 3: Is the Greasemonkey script the current version? If not, the page offers the download link for the latest version.

Success: The browser is properly configured. The user is allowed to continue if all checks pass.

Implementing the Solution

I didn't include the code in this blog but it is attached here. The code is fairly short, and so you should be able to repurpose it for your needs quickly. Also, for illustration, I have deployed an online demo.

Online Demo

I am hoping others will provide alternative solutions - please speak up if you have built one. The solution I built is passive - it requires the user to navigate across the Gateway page. It is easy to imagine a more active solution, one that would use an XmlHttpRequest to periodically phone home to see if an updated script has been published. That type of solution would need to cache the answer, otherwise it's impact to the network could be substantial. I would think that the GM preference store could be used as a cache.

Greasemonkey Versioning on the Web:

There are others who have talked about the versioning issue. Here are some links:

GMVC (Greasemonkey Version Control)

"The objective of this project is to create a database-driven repository of GreaseMonkey Userscripts which allows for the archiving of previous versions, the release of production versions and the limited released of alpha and beta test versions through the same site."

AllPeers Blog Entry

"A first step would be to give web authors at least the option of making their sites script-friendly. This would involve placing a special header on their webpages that can be tied to a specific version of a Greasemonkey script, like so:

<head> <meta greasemonkey:somescript.js="1.2"/> </head> "

Jeff Barr's Blog

"At some point I could see the need for what we could call "Enterprise Greasemonkey," a tightly packaged version of Greasemonkey with a number of scripts installed and locked in to place. This would give system administrators the ability to deploy specialized versions of Firefox to users who don't need to know how to install, customize, or disable Greasemonkey scripts."