en | Technical

This page contains information that some users and reviewers would be interested in but that is too technical to be included in the main user help documentation.

Note that there is a separate page for developers who wish to contribute to the project (as well as information about other ways to contribute)

Visual Studio Projects

The KeeFox Visual Studio solution contains the following projects.

Firefox addon: This is what most people think of as KeeFox - it is the files that make up the .xpi which is installed into a user's browser. The "deps" sub-folder will be populated with the output from several other projects and is also the download destination for any 3rd party dependencies which need to be installed during KeeFox setup (i.e. KeePass and .NET)

KeePassRPC: This is a KeePass plugin which adds a JSON-RPC server to KeePass that a JSON-RPC client (e.g. the KeeFox add-on) can connect to in order to interact with KeePass and the database loaded within it.

Jayrock and Jayrock.JSON: These libraries provide a basic JSON-RPC server. See http://jayrock.berlios.de/ for more details.

KeeFox Elevate: This simple native windows executable wraps any other executable with a request for privilege escalation. It is used during the KeeFox setup process primarily to ensure that administrators on Vista/7 are able to install applications.

KeePassRPC Copier: This simply copies the KeePassRPC plugin file to a new location; used as part of the setup procedure.

Check For Admin Rights: This simple native windows executable can determine whether the currently logged on user has administrative privileges on the machine. It is executed automatically before the KeeFox setup page is displayed (just after installing the add-on) in order that the appropriate setup procedure can be presented to the user.

KeePassRPC API

Please see these two posts on the KeeFox website:

http://keefox.org/2010/keepassrpc-plugin-technical-overview

http://keefox.org/2010/keepassrpc-security-and-authentication

Firefox Add-on Messaging Service (FAMS)

FAMS provides secure messaging services to Firefox add-ons. You can read more about it here.

Using locales.js outside of KeeFox

1. Grab the latest locales.js

2. Include it in your add-on (e.g.: Components.utils.import("resource://addonNameModules/locales.js");)

3. Modify it to match your add-on's name:

   var EXPORTED_SYMBOLS = ["KFandFAMSLocalisation"]; => var EXPORTED_SYMBOLS = ["YourAddonNameLocalisation"];

   function KFandFAMSLocalisation(chromeURIs, jsonLocales) => function YourAddonNameLocalisation(chromeURIs, jsonLocales)

4. Initialise:

   this.locale = new YourAddonNameLocalisation(["chrome://addonname/locale/addonname.properties","chrome://addonname/locale/addonname.extra.properties"]);
   // This example uses only Chrome URIs but you could pass in JSON directly instead / also.

5. Use in Javascript:

   locale.$STRF(key, formatArgs); // or locale.$STR(key);

6. Use in XUL:

   window.addEventListener("load", function () {
   ...locale.internationaliseElements(this.document,
   ['array','of','IDs','of','elements','to','be','processed'],
   ['array of attribute names that will be localised','e.g.:','label','tooltiptext','accesskey'] // The text content of each matching element will also be localised ); }, false);

Supplying JSON localisations

You can supply your localisations in JSON format if that's easier (e.g. internet delivery or sharing translation work with a Chrome add-on). Either supply a Chrome localisation JSON object for the user's current locale* or supply a single JSON object that contains translations for all locales. If you're interested in the latter, just use the following example structure as a guide:

{
// This identifies the version of this structure. Maybe it will never be updated but we cover ourselves just in case and  
can also use it as a convenient check to establish whether a given chunk of JSON is in this format or in Google Chrome's l10n format
"schemaVersion": 1,

// Each locale is contained in an object identified by it's code name (the same one used by normal Firefox localisation)
"<locale-code>":
{
// The unique string name identifier contains the translated string value
// <string value> can contain replacement placeholders as per .properties files (e.g. %s)
"<string name>": "<string value>"
}
//, More locale objects
}    

* In practice, I expect a few more hours of work will be needed before the Chrome format is a useful alternative. For example, parameters won't work yet (mainly becuase Chrome takes a different approach to parameter selection but also becuase it's not been a priority for me to implement that feature yet). Feel free to implement and send a pull request. See http://developer.chrome.com/extensions/i18n-messages.html for more details on the Chrome format.

Version numbering

KeeFox versions are typically released with up to 3 numbers and optional alphanumeric suffixes:

n1.n2.n3[ln]

where n = a number and l = a letter

n1: Major version. This was incremented from 0 to 1 to indicate the stable release of the core features required to ensure KeeFox worked well enough for everyday use. An upgrade to 2 may happen one day but exactly what changes would justify such a change is currently unknown.

n2: Minor version number. An increase to this number implies a significant number of changes and new features.

n3: Release version. Most minor versions will go through several iterations while being beta tested and while the next minor version number is being developed. Once a minor version has been released as a stable version, release version changes would typically be released only to fix bugs, add/improve language support or ensure support for new changes to KeePass and Firefox.

ln: A code letter indicating the stability of a given release followed by a number indicating the number of releases at the level of stability. Releases with no letters are considered stable. Current letters are:

b (Beta): A release that may be good enough to become a stable release but which requires more widespread testing by development channel users.

a (Alpha): A release that has passed basic tests and typically will have been used by at least one person for a couple of weeks with no obvious signs of significant problems. Alpha releases may not be feature-complete and are more likely to have unexpected problems than a beta release.

Many releases will appear to be skipped for administrative reasons, to enable easier and faster development and ensure a reliable upgrade path from earlier versions.

When only the major and minor release numbers are mentioned, we're referring to all (or unspecified) releases for that major.minor version of KeeFox. Less frequently we'll refer to major.minor.* - so for example, 1.2 is the same as 1.2.x

Here's an example: 1.2.3b7 is the 7th beta release of the 3rd release of KeeFox 1.2