New Entry configuration format

[luckyrat]

To allow a number of improvements to Kee, and potentially assist with Kee Vault mobile app improvements, we must modify the format used by KeePassRPC to apply configuration to an entry.

Some ideas:

• Persist in a different format than JSON? Or at least wrap the configuration in a way that can identify the persisted format to reduce compatibility problems if we want to pick a more space-efficient format in future.
• Flexible types - challenging when it comes to a UI for editing within KeePass but perhaps would work if we just pass through any unknown types unmodified. This would let Kee or other clients define new types before KeePassRPC has first-hand knowledge of them.
• Separate objects to represent field locators (e.g. HTML attributes, labels, CSS selectors, Android accessibility paths).
• Entry locators? Allow with a bonus score (potentially negative) or block the entry from matching if a specific locator is matched.
• Locator objects, or similar could aid detection of signup, password change and sign-in forms, as well as 3rd party authentication flows.
• Enum rather than multiple bools to represent entry automation options.
• Possibly enables or depends upon Store KeePassRPC data in CustomData instead of an advanced string #24 but mostly orthogonal.

[luckyrat]

I've been looking into this recently and begun implementing an approach that works well for Kee and shouldn't prohibit extension for other KeePassRPC clients in future. I'll summarise the entire new config format once I'm sure it is going to work as I expect but in the mean time thought it was time to update my earlier points...

Persist in a different format than JSON? Or at least wrap the configuration in a way that can identify the persisted format to reduce compatibility problems if we want to pick a more space-efficient format in future.

Storing behind a key called "KPRPC JSON" is sufficient for us to be able to switch to a different format if desired in future but right now the storage capacity and performance characteristics of our persistence format are not a significant bottleneck we need to address.

Flexible types - challenging when it comes to a UI for editing within KeePass but perhaps would work if we just pass through any unknown types unmodified. This would let Kee or other clients define new types before KeePassRPC has first-hand knowledge of them.

Won't do this. Only really practical in Kee Vault - KeePass' reliance on .NET Framework makes this impossible without introducing significant risks and performance impacts, and it would take a prohibitively long time to implement anyway.

Maybe worth noting that there are 2 types of type we're frequently concerned with - the underlying logical type of the stored value (usually text or a password) and the HTML form field type (e.g. text, password, radio button). We'll split these two concepts in the new configuration format so it should be easier to add new variants of either category of type in future, albeit changes to both client and server are likely to be required in many cases.

Separate objects to represent field locators (e.g. HTML attributes, labels, CSS selectors, Android accessibility paths).
Entry locators? Allow with a bonus score (potentially negative) or block the entry from matching if a specific locator is matched.

EntryMatcher and FieldMatcher classes can now represent this information when combined with their corresponding Configuration object (associating a Matching method with weight and action.

At least to start with, much of this configuration potential will be unused but once Kee has also been updated to understand the information we can offer a range of new web page form and field matching and prioritisation options.

Locator objects, or similar could aid detection of signup, password change and sign-in forms, as well as 3rd party authentication flows.

Won't do this now. Can add later if we identify a strong enough benefit and clearer definition of the idea.

Enum rather than multiple bools to represent entry automation options.

Will do this for Automation configuration and various other enumerable properties. We make the storage optimisation of assuming the default value of the enum will not change between serialisation and deserialisation so if we ever want to change the default, we'll have to deal with that then (e.g. migrating the property to a new name).

Possibly enables or depends upon Store KeePassRPC data in CustomData instead of an advanced string #24 but mostly orthogonal.

Likely will be much easier to implement as part of the migration to Custom Data so that's what we will do so that we are able to complete this work in a timely manner.