function getVersion(addonID) {
		var extMan = Components.classes["@mozilla.org/extensions/manager;1"].getService(Components.interfaces.nsIExtensionManager);
		var ext = extMan.getItemForID(addonID);
		ext.QueryInterface(Components.interfaces.nsIUpdateItem);
		return ext.version;
}

// usage
var version = getVersion("{my addon id}");

Inputting your addon ID, you will get your version number back. Inside the method, the variable ext (nsIUpdateItem) has a lot more metadata properties you can use as well if you so choose.

However, in the new Firefox version 4, the addon APIs have totally changed. The call to get the addon metadata has changed from synchronous to asynchronous which tends throws a spanner into the works. There seems to be a tendency to migrate all javascript data calls to asynchronous to avoid freezing the UI. Thus, rewriting getVersion means rewriting all the consumers to expect asynchronous operations. Here’s the new version that supports Firefox versions 2 to 4.

function getVersion(addonID, callback) {
	var ascope = { };

	if (typeof(Components.classes["@mozilla.org/extensions/manager;1"]) != 'undefined') {
		var extMan = Components.classes["@mozilla.org/extensions/manager;1"].getService(Components.interfaces.nsIExtensionManager);
		var ext = extMan.getItemForID(addonID);
		ext.QueryInterface(Components.interfaces.nsIUpdateItem);
		callback(ext.version);
		return;
	}

	if (typeof(Components.utils) != 'undefined' && typeof(Components.utils.import) != 'undefined') {
		Components.utils.import("resource://gre/modules/AddonManager.jsm", ascope);
	}

	ascope.AddonManager.getAddonByID(addonID, function (addon) { callback(addon.version); } );

}

// usage:
var version;
getVersion("{my addon id}", function(ver) { version = ver; });
// you don't know when version will be populated

Generally, in my use cases, I need to get the version and I don’t want to continue on until I have the version. Other than rewriting, the only workaround is to fetch the version number on extension start up and cache it somewhere. Thus all subsequent get version calls will get that cached number synchronously. Such a pain :/

What I’m suggesting here I guess is to rethink Thinderbird – lose the focus on mail, in favour of more interesting communication mediums like IM, Facebook and MySpace. With the launch of OpenSocial from Google, connecting to social networks should be made much more easily. Thunderbird can utilise these APIs to bring users of social networks what it brought to email users in the past. There is a growing user base of social networks and it’s only getting larger. With many users part of several networks, managing their identities across these networks can become a painful and time-consuming. An application that manages multiple networks, a social network aggregator if you will, is something that we be desired of from these users. Thunderbird can handle multiple email accounts and it doesn’t take much to see that a natural evolution would be handling multiple social network accounts.

The new functionality, like managing social networks can’t be tacked on like an extra arm to the email functionality. There has to be a rethink from ground up. Right now the interface of Thunderbird is that of traditional email clients. You have accounts and folders and emails. This legacy model will be hard and awkward to reconcile with newer social networking models. Classification of messages/emails are no longer done with folders but with tags that allow them to he connected to multiple categories. Instead of the ‘address book’ you now have ‘friends’ and you certainly want to tag them.

Whether this new application, be it Thunderbird or a something brand new, there exists an opportunity to fill an enormous and growing void. Thunderbird is at crossroads and if there is a better time for a new direction, it would be now. In the post, I’ve mainly talked about one facet, which is social networking, but there are many other facets (IM/VoIP/Cal?) I believe should be part of the broader Thunderbird strategy. Aggregating all the different types of communication is surely a role that fits a next generation Thunderbird. This idea is not new and some members of the community share similar views.

Remember, as the /. meme goes, in Korea, only old people use email.

The PHP code I wrote is simple and can be inserted into the top of any PHP script. The key output is $user $domain $workstation, which is the information advertised by the user. Be warned though, the script does NOT authenticate the user and merely assumes that the user is who they say they are. This is akin to a user entering only a username with no password required. I plan to add password/hash verification possibly in conjuction with samba in the future.

A limitation is that the PHP script relies on apache_request_headers() which is only available if you run PHP as a apache module.

You can get the source of the PHP code here.

If you try the script in Firefox (on windows), you will notice that you get prompted for a username and password when encountering an NTLM challenge. This is because sending your windows credentials to any unscrupulous website poses a real security risk. To make it automatically use your windows credentials for sites you trust, you can add the website to a whitelist.

The whitelist is located at Firefox’s about:config (type that into the address bar), which allows the editing of all of the browser’s preferences. Find the preference entry network.automatic-ntlm-auth.trusted-uris, double click on it and type the hostname of the site (ie http://www.abc.com) that you want in your whitelist. Multiple entries are seperated by commas. After doing that, Firefox should send your windows creds automatically.

Update 20/09/2009. The above script is outdated, anyone wishing to use NTLM should see the new post: Part 2 – Now with hash checking

I’m happy to say that this is now ready for testing. Below is a working build for Windows. It is based on the latest Trunk plus the cookie patch and extension. Unfortunately for Mac and Linux users that wish to try the patch, they will have to manually compile Firefox with the patch below.

Note that this build is meant for users who are familiar with using Firefox test builds and not intended for production. You are recommended to create a new profile. If you intend to use an existing Firefox Trunk profile on the cookie patched Firefox, the only caveat is that your old session store (windows and tabs saving) cookies will not be restored (but long term cookies will be there). Similarly when transitioning back from the patched Firefox to normal Firefox, you will lose the session cookies, but also will be unable to access cookies saved in containers other than Jar A.

In the patched Firefox, to use the new container, or “jars”, just click on the jar icon in the far right of the status bar. The letter represents the current selected jar for this tab. You can assign a different jar letters to each tab. Cookies from all accessed pages will be deposited in this jar. If you open a link in a new window/tab, the jar letter should carry forward to the next window/tab.

All long term cookies are saved in the Firefox profile folder. Jar A will be saved as cookies.txt and compatible with older Firefox. Jar B will be saved as cookies_B.txt and Jar C cookies_C.txt

There is a known issue in which if you have the cookie manager open while browsing, it will incorrectly show cookies listed. This is just a GUI issue and doesn’t affect the core functionality.

Compiled Firefox for Windows

To compile with the patch yourself, download and apply the patch the trunk (made against 13-May-2007). In the compiled result dist/bin extract cookiejarschrome.zip into the chrome subfolder.

Patch for trunk source
cookiejarschrome.zip

Edit: Fixed links