Ongoing KeePassRPC Authorisation in Firefox


everytime Kee connects to KeePass I am forced to provide an authorisation key.

First of all: Yes, I´ve read and understood everything posted here:

My settings:

  • Kee & KeePassRPC security setting set to MEDIUM
  • Expiry time set to 2160 hours
  • KeePassRPC setting tab “Authorised clients” shows a valid session with expiration time matching expiry time

Therefore I´m pretty sure Kee can´t (permanently) store the authorisation information.

Can you please tell me where it´s stored in Firefox? I have a few security addons in Firefox (Disconnect, HTTPS Everywhere, NoScript, PassSec+, Referer Modifier, uBlock Origin), but ruled them out by creating a new Firefox user profile (same result).

I have no idea if the RPC plugin or the Firefox addon is the root cause here. Please help to sort this VERY annoying bug out!


Here are the details for the storage locations. Hopefully this helps you to narrow down which side of the connection is not working properly and we can take it from there.

Storage locations



(<FIREFOX_PROFILE_LOCATION> can be found by typing about:profiles into your address bar)

The JSON data stored within that file may vary in future but at the moment the encryption key will be stored in a pair of properties like this:


NB: This file location is correct as of Firefox 59 but may be modified at Mozilla’s whim so if you can’t find it, double check with Mozilla where it should be for your version and operating system.


In an XML file located according to the documentation at there will be some XML similar to this:


I´m still trying to investigate. First suspicious findings are #2 and #3:

  1. OKAY:
    Value “KeePassRPC.Key.” from “KeePass.config.xml” matches “extensions.keefox@chris.tomlinson.KPRPCStoredKey” and “extensions.keefox@chris.tomlinson.KPRPCUsername” from “prefs.js”

    Value of “KPRPCUsername” from “storage.js” is different from the ones above.

    “extensions.keefox@chris.tomlinson.keePassRPCInstalledLocation” from “prefs.js” is empty --> ???

Any ideas on this?

Updates on finding #2:

  • According to plugin options the UID from the NOT connected authorised client is the same ID as used in “KeePass.config.xml” and “prefs.js”.
  • BUT: the “new” and active session UID (see connected = true) only matches the values from “storage.js”
  • I also noticed the name of authorised clients is different: one is KeeFox, one is Kee. Is there a rest of the old plugin in Firefox? According to extensions tab it isn´t.
  • In about:config I also see “extensions.keefox@chris.tomlinson.lastConnectedToKeePass” key with value “20171114T18:43:14Z” --> are those configs from the old plugin? If so, how to purge them from Firefox? Uninstall & install of new Kee addon already done, no changes.


  1. I simply removed the most likely old (from old KeeFox addon) preference settings in “prefs.js”, removed and reinstalled Kee addon. No changes at all.
  2. The new authorised client (revoked all others manually) points to the core problem: as you can see the expiration date/time is in the past. To be more specific: it´s the starting time of KeePass. (Update 16:25: no it isn´t. It´s the Kee Firefox addon key request time exactly ONE HOUR IN THE PAST).

So even all settings are correct, the new client authorisation simply ignores that expiration value when creating a new authorisation !!!

Still don´t know where the root cause is, at the moment I´d point to the KeePassRPC plugin.

It looks like the expiry time is being applied correctly (2019 rather than 2018).

As you discovered, the settings in prefs.js and about:config are from KeeFox 1.x. You can manually delete the settings from about:config but they have no effect on Kee (version 2 is not allowed to even see those settings, let alone remove them to tidy up).

If you restart KeePass while connected to Kee, does the current connected unique ID entry from “Authorised clients” get replaced with a new entry?

If so, that indicates that KeePass is not able to save its configuration file. I suspect this is the case since your “finding #1” indicates that KeePass.config.xml contains an old ID. Although it is possible that you’re not looking at the correct config.xml file though since the KeePass configuration hierarchy can be complex.

If it looks like that is the case and you can’t see any obvious file permission reasons for the write to fail, I expect the KeePass community on their forum would be able to help you narrow down what is going wrong.

It looks like the expiry time is being applied correctly (2019 rather than 2018).

Oh indeed, it´s set to one year. I didn´t see the 2019 and thought 2018, my fault.

If you restart KeePass while connected to Kee, does the current connected unique ID entry from “Authorised clients” get replaced with a new entry?

Interesting: no, it doesn´t. List of authorised clients keeps unchanged, even Kee once again prompted to authorize as soon KeePass is (re)started.

I have no write access (file permissions) issues, e. g. “C:\Users%username%\AppData\Roaming\KeePass\KeePass.config.xml” is fine and updated according to timestamp on a regular basis (when using KeePass). Kee files are in Firefox profile folder which also is fine. KeePassRPC is in plugin folder, everything default…

To be honest: I absolutely don´t know what else to check or try. Therefore really looking forward for any further assitance on this.

Oh dear… you will never imagine what´s the reason for this behaviour!

Short story: It was a rights issue on the Windows application side. The information simply couldn´t be stored.

Workaround: (Always) start KeePass in admin mode.

I don´t know why this is the case, KeePass is normally installed at “C:\Program Files (x86)\KeePass”, nothing special here.

If anyone has an idea on this that would be great. Or is it the “normal process” to start KeePass with admin rights? Well, it´s not on my other Windows machines…

I even reinstalled KeePass… no change. When starting it without admin rights, settings can not be saved/stored permanently. No idea where user settings data is stored. All my other Windows clients run KP in portable mode…

Ideas on this?

No, that is not normally required.

You’d probably be best looking on the KeePass forum for further assistance since they have probably got more experience with similar issues than most people here. Maybe look more closely at all the different KeePass configuration file options since you may have something configured which forces KeePass to try to write data into a system-protected location rather than your user folder.

THX, will try my luck there. Thank you @luckyrat.