Creating a Universal updateURL

In the discussion of the Firefox rapid release process, one of the complaints has been that add-ons that are not hosted on addons.mozilla.org (AMO) don’t get automatically bumped to be current with the latest Firefox. I needed to solve this problem for one of my clients, and here’s what I came up with.

Add-ons that are not hosted on AMO specify the location for their updates via an updateURL in their install.rdf file. What makes this useful for our purposes is that there are variables that can be placed in the updateURL that will be filled in by Firefox when it requests the update. We can use those variables to create an update file that always says the current version is compatible.

Passing our extension ID and version looks like this in an updateURL (Remember updateURLs need to be served as https):

https://example.com/update.rdf?id=%ITEM_ID%&version=%ITEM_VERSION%

Then we can generate the appropriate RDF file on the server based on the parameters that are passed to update.rdf:

<?
header('Content-type: application/xml');
echo('<?xml version="1.0" encoding="UTF-8"?>');
?>

<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:em="http://www.mozilla.org/2004/em-rdf#">
<?
if (isset($_GET['id']) &amp;&amp; isset($_GET['version'])) {
  $id = htmlspecialchars($_GET['id']);
  $version = htmlspecialchars($_GET['version']);
?>
  <RDF:Description about="urn:mozilla:extension:<?=$id?>">
    <em:updates>
      <RDF:Seq>
        <RDF:li resource="urn:mozilla:extension:<?=$id?>:<?=$version?>"/>
      </RDF:Seq>
    </em:updates>
  </RDF:Description>

  <RDF:Description about="urn:mozilla:extension:<?=$id?>:<?=$version?>">
    <em:version><?=$version?></em:version>
    <em:targetApplication>
      <Description>
        <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
        <em:minVersion>3.6</em:minVersion>
        <em:maxVersion>*</em:maxVersion>
      </Description>
    </em:targetApplication>
  </RDF:Description>
<? } ?>
</RDF:RDF>

And there you have it. An RDF file that always says that the add-on that it was called with is compatible with the latest Firefox.

One other note. When I was testing this locally, I ran into problems debugging using a self-signed cert. The add-on update checker requires that the certs being used be built in certs. You can work around this by adding the boolean preference extensions.update.requireBuiltInCerts and setting it to false.

Update: Dave Townsend (Mossop) had a great suggestion. Pass the appVersion as well:

https://brandthunder.com/update.rdf?id=%ITEM_ID%&version=%ITEM_VERSION%&app_version=%APP_VERSION%

and then use that version instead of hardcoding maxVersion.

$appVersion = $_GET['app_version'];
...
<em:minVersion>3.6</em:minVersion>
<em:maxVersion><?=$appVersion?></em:maxVersion>

Then you never need to change those values (unless something becomes incompatible).

Another update: Per tito in the comments, I added calls to htmlspecialchars to santize the inputs.

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *

9 thoughts on “Creating a Universal updateURL

  1. Note that with this, if your extensions happens to really be incompatible and break a newer Firefox either in UI or code, then for everyone using it, their browser will render dysfunctional with no way out unless they know how to get into safe mode.

    • I’m certainly not advocating this for every add-on. People still need to do some basic testing.

      But honestly, this is what AMO is doing. They aren’t installing every add-on they bump. They are guessing based on some sniffing of code.

  2. Hallo just for your info:

    “The use of “text/xml” has been criticized as a potential source of encoding problems and is now in the process of being deprecated.”
    http://en.wikipedia.org/wiki/XML

    Use application/xml instead. And please avoid short tags (btw PHP 5.4 will allow <?= *hint* *hint*).

    • Yeah, I’ve never been a fan of the McCoy process.

      Especially after I did that for the CCKs at IBM and then lost the key I used to sign them so I could never get sign the next update to get those users updated 🙂