Just wanted to share my findings on finally solving a KeepassRPC authorization problem that has plagued me intermittently for years, despite reviewing the troubleshooting steps listed in the documentation, which did not help. This MAY not apply to or solve everyone’s issue, but it solved mine, and I believe it is possible for it to apply to a good number of realistic configurations and it does not seem to be described in the documentation.
The particular problem I’m describing will only occur if you are using more than one browser or browser profile with a single shared Keepass database.
This could occur if:
You have two browsers on different computers with a synchronized or shared browser profile, and a synchronized or shared Keepass database.
You have two browser profiles or two browser versions on the same computer, both sharing the same Keepass database.
Note that KeePass’s built-in “Synchronize” feature also appears to synchronize KeePassRPC access keys, so even if the physical databases being accessed are separate, if they are synchronized with each other, this problem can still occur.
The issue occurs when the two separate profiles end up using the same “unique” ID to access KeepassRPC, but each using their own actually-unique access key. This results in each browser profile overwriting the other browser’s authorization key. The next profile then tries to access KeepassRPC with it’s own (now overwritten and thus invalidated) authorization, which fails, so it requests a new one and overwrites it once again. The vicious cycle continues every time a different profile loads the database.
The easiest way to see if this is occurring with your installation is to start one of the affected browser profiles, then open the KeePassRPC options window from within KeePass, and select the Authorized clients tab. Note the “Unique ID” of the active session. Then close that browser, open another profile or browser, and the authorization dialog will likely appear. After that, again check the “Unique ID” for the active session again, and if it is the same, then both browsers are sharing the same “Unique ID” and the conflict causes them to overwrite each other’s authorization key.
This situation can be easily repaired by opening about:config, searching for the offending duplicated key, and changing it to something actually unique for each affected browser.
Tested with Keefox specifically, but I am fairly confident Kee 2.0+ could also be affected and repaired in the same way. Hope this helps some people.
Configuration in Firefox 57 (and hence Kee 2.0+) is fundamentally different to earlier versions - there is no built-in support for synchronising settings across different browsers (well, technically there is but it is far too limited to be functional for all but the most trivial of situations… and KeeFox/Kee is not such a trivial case).
When data is migrated from KeeFox to Kee, the unique ID is not preserved so any existing problem with KeeFox would not persist when starting to use Kee.
It’s therefore unlikely that this problem would affect Kee 2.0 users. It’s still possible if people manually mess around with Firefox profiles on the filesystem and clone them in some fashion, but it’s much more difficult to get into that state where the unique IDs become non-unique.
It would also require a different resolution (since about:config is no longer usable by addons). The easiest approach would be to uninstall Kee, restart Firefox and then reinstall it again - Firefox will then delete all configuration for the addon. Unlike in earlier versions of Firefox, v57+ does not allow add-on configuration to remain on the Firefox profile after uninstallation.
Technically, one could modify the ID stored in the config file that Firefox persists to disk for each addon but the specific location of this file is not fixed so if anyone needs to do that, you’ll need to research what the current location is for your version of Firefox on your operating system.
I have the exact same problem with KeePass/KeyFox on two browsers (Firefox 42 and Pale Moon 27.9.2) on one Windows 7 computer. And as you indicated, both are sharing a KeePassRPC “Unique ID”.
But when I go to about:config, on one of the browsers, there are two entries.The first entry has a Preference Name of:
extensions.keefox@chris.tomlinson.KPRPCUsername, and has a Value of , in my case, f7aa4b87 etc.
The 2nd entry has a Preference Name of:
extensions.keefox@chris.tomlinson.KPRPCStoredKey- f7aa4b87 etc., and no Value field entry.
I changed the Value on the 1st entry, but that did NOT change the Preference Name on the 2nd entry. If I try to change the 2nd entry manually, my change is entered in its Value field, and does not change the Preference Name.
So I need a little more clarification on exactly what gets changed where, before I mess up my about:config.
Changing just the value of extensions.keefox@chris.tomlinson.KPRPCUsername should suffice. As long as you ensure that it remains a valid UUID/GUID after modification then when KeeFox next attempts to connect to KeePass, the new value will be used and after successful authorisation, the secret key will be stored. Note that in the default configuration (“medium” security) the KPRPCStoredKey about:config entry will not be used so don’t worry if that remains empty.
First I checked. On the KeePassRPC (KeeFox) options page, my KeePass security level and my Minimum acceptable client security level are both set to Medium, which you said was the default.
Then I went to about:config on Firefox (the 2nd browser) and changed the value of extensions.keefox@chris.tomlinson.KPRPCUsername. The original was: f7aa4b87-d212-4d1b-9aa3-2eb40aaec78f. I first changed just the last three digits, from 78f to 81g. I then Exited Firefox and opened it again. The Value in about:config had been changed, but the same problem occurred. Then I decided to also change the 1st 8 digits, from f7aa4b87 to f8bb3a78.
Exited Firefox, and and opened it again. The Value in about:config had been changed, but the same problem again occurred. And when I open the KeePassRPC (KeeFox) options page, the ORIGINAL Unique ID still shows.
I noticed that on the KeePassRPC (KeeFox) options page that there was a 2nd entry with a different Unique ID. I have/had no idea why this was there. So I went back to Firefox, and entered the Unique ID from that 2nd entry, since I assume that it was a valid ID. The same problem still exists.
Obviously I have no idea what I am doing here, so if you think I may have missed something, let me know.
Thanks. I did some internet searching. I found that what I have is known as a version 4 UUID.
Then I found this website: https://www.famkruithof.net/uuid/uuidgen
which will create unique version 4 UUID’s. I created two of them. Neither worked when I made the changes in Firefox. (I rebooted my computer after each change, just in case that was needed.)
So clearly there is something here that I am missing. Any further thoughts?
This issue s NOT solved. Perhaps my recent postings and notifications got lost in the website problems you recently posted about.
As I said in this thread, and also in {https://forum.kee.pm/t/keepass-when-using-two-browsers/1312}
the first entry has a Preference Name of: extensions.keefox@chris.tomlinson.KPRPCUsername, and has a Value of , in my case, f7aa4b87-d212-4d1b-9aa3-2eb40aaec78f. I determined that this value is a version 4 UUID.
This website {https://www.famkruithof.net/uuid/uuidgen} will create unique version 4 UUID’s, as long as you select ‘Version 4: Random’. So I created a unique UUID, and made the change in Firefox. I then Exited Firefox and opened it again. The Value in about:config had been changed, but the same problem occurred. I tried this several times with different UUID’s, with the same result. I even tried rebooting my computer after the changes, just in case that was needed, but that did not help.
The 2nd entry has a Preference Name of: extensions.keefox@chris.tomlinson.KPRPCStoredKey- f7aa4b87-d212-4d1b-9aa3-2eb40aaec78f, and no Value field entry. You previously said that it is not necessary to make any changes on this line.
So I am at a dead end. Either I do not have enough information to fix the problem, or I am doing something wrong.
In case you still find this topic unsolved. The critical data for the case of a shared browser profile (I mean physically shared, like a shared folder containing the actual profile) is storage.js file inside the browser extension’s directory, keefox@chris.tomlinson in the case of FF. This cannot (!) be shared among different KeePassRPC clients. So, what you basically need is to “unshare” this folder (make a symbolik link – mklink /d for Windows – from another dir distinct to each system sharing the browser profile, e.g. from %AppData%\Mozilla\Extensions\keefox@chris.tomlinson to the original location inside the shared profile), and recompile the KeePassRPC plugin (disable and re-enable it again), so it regenerates its key which will be then unique for each of your systems you are using. Thus, you can separately authenticate Kee browser add-on on each system as a distinct client for KeePassRPC, each of them having a unique key. No more continuous reauthentication of the Kee browser extension (after you authenticate it once for every system in use). They just appear to be different clients. And yes, you can still use a shared Keepass database (or not, as you wish).
I am sorry but similar problem here:
FF 66.0.1
Kee 3.0.2
KeePassRPC 1.8
KeePass 2.41
First time after booting system and FF/Kee is started it reclaims reauthentication of the Kee browser extension. If done, next start of FF/Kee works without authentication. KeePassRPC adds new ‘Authorised clients’.
I did check it with new FF profile:
Same behaviour, after booting system and FF/Kee is started it reclaims reauthentication of the Kee browser extension.
Thx + regards.
Nothing has changed in Kee but I suspect you may be referring to some changes that Firefox made recently. I don’t know much about it because I’m only dealing with the WebExtensions API that Firefox offers to Kee but I have heard that Firefox now stores all WebExtensions settings in an IndexedDB database rather a JSON file (presumably this was the storage.js file that you mention).
If anyone finds out what this means for the workarounds previously discussed in this thread and can suggest next steps for anyone affected by that change I’m sure others following along would appreciate that.
(since I’m a new user, my posts are apparently limited to 3 only, so I had to reedit this one)
OK. Here’s a new workaround. Sorry it took me so long, but I really didn’t have much time to work on this.
So, now you have to “unshare” (use symlink for Linux or symlink/junction for Windows) the new folder, in which the newest versions of FF store your Kee add-on settings. That will be one of your_profile/storage/default/moz-extension+++* directories. Which one it actually is, you can easily guess e.g. running your FF and going to Kee add-on options (look at the URL). This is the folder to unshare (you have to unshare that whole folder, not the idb/ one inside!) for every operating system you shall use.
And now comes the tricky part. Inside the unshared directory, you will find idb/3647222921wleabcEoxlt-eengsairo.sqlite SQLite database which stores the add-on id (and its key), as registered with KeePassRPC plugin. Never mind the key (at least for our workaroud), but the id must be different for each and every particular instance of Kee (for each operating system). Well, you have to change it (changing even one byte should be enough). As a result, each Kee will register with KeePassRPC using a different id.
Well, it worked for me, that’s all I can guarantee.