In this version we have made significant changes to how we record configuration of entries and their form fields. In almost all cases there will be no visible impact of the change but it allows us to add a variety of long-desired features to Kee in future. Rolling back to version 1.x is not possible without a corresponding rollback to your backup KDBX file so please check everything works correctly before making a lot of changes to the information stored in your KDBX file.
Changes to field TYPE
The most visible change is a change to how you can configure the type of a field. Until now, every “form field” in a KeePass entry could have a type which matched exactly to a specific HTML (DOM) type (with the exception of a magic “username” type which was in most cases identical to a “text” type). We already understand that “text” type fields could be inserted into DOM fields with types of “text”, “email”, etc. but the need for greater flexibility for these and other types have led us to a new way to define types.
You will now assign a conceptual type to a form field, rather than a specific DOM type. For example, a field with a “Toggle” type indicates that the field controls something that can be turned on or off, enabled or disabled, activated or deactivated etc. Kee can then use this type information to find the best type of field to match in a web page (in this case, the most common match would be a DOM type of “checkbox”).
The new “Existing” type is the most impactful. This represents a type of field where the value of the field is expected to be found (already existing) on the web page. When Kee finds a field with this type, it can consider a match for any suitable DOM field type (an item in a dropdown “select” menu or a radio button are the two most common examples).
In the unlikely event that you need to restrict a field match to a specific DOM type, you can still specify this manually with the new “DOM type” property.
Although not currently visible, there is also an understanding of some other types, such as an “OTP” type which might be used in the future to enable Kee to improve the experience for those of you that store your 2nd factor TOTP codes inside your KeePass Entries.
DOM Selector
Another change in the form field editing view is the ability to store a “DOM selector”. This currently has no effect but we will be able to use it in future to experiment with an additional way to find the best field to fill on a web page. We recommend ignoring it for the time being.
Breaking changes and compatibility
Entries saved using this version may have missing data or settings if you load your database with an older version of the plugin so a rollback after editing entries will require either restoring from a backup or reverting to an older version of an entry (assuming you have entry history enabled and don’t make too many changes in the mean time).
Our Entry configuration is now stored in a “Plugin Data” location rather than a String field. We will eventually tidy up your KeePass entries automatically to remove the old “KPRPC JSON” String but are leaving it in place for the time being. Note that any manual manipulation of this old String field will no longer have any effect on Kee.
Using Version 2 will cause KeePass to save your file using KDBX version 4.0 or 4.1. Since KeePass 2.57 will default to this newer format too, we don’t anticipate many problems. Compatibility with other KeePass ports can’t be guaranteed but should be fine as long as they support the recent KDBX file format. Again, we recommend thorough testing while your KDBX file backups are still up to date in case you have to temporarily roll back to an older version.
Kee Vault has also been updated to understand these new formats so you shouldn’t find any problems when exporting/importing between KeePass and Kee Vault, provided that you are using the latest versions of each.
When connecting to clients that don’t understand the new form field configuration format (this includes the current version of Kee), KeePassRPC will specify that all form fields with an “Existing” type must match a radio button form field, unless the Entry’s form field has also been assigned the “select-one” DOM type in which case it must match a dropdown (select) field instead. Migrations of your existing data and new entries created by the existing version of Kee will work just fine but if you create new entries from scratch you will have to type “select-one” into the new “DOM type” box if you want to match on a dropdown (select) box instead of a radio button.
Feedback welcome
Version 2.0 is available for beta testing now at Release 2.0.0 · kee-org/keepassrpc · GitHub and we’d really appreciate you trying it out and letting us know how well it works for you.