Kee has always supported sign-in systems that require multiple steps but in recent years it has become quite a challenge to work with these websites smoothly. The reasons for that, and reasons for posting this topic are similar to those discussed in the password saving improvements topic and the improvements being planned in that topic will also allow us to refine this aspect of Kee.
In a future version of Kee we will present each page/step as an entirely independent entry when matching or searching. In some situations this could be a breaking change. Without manual inspection of every entry in your database source it is not possible to identify if you will be adversely affected by this. If you know that you have manipulated the page number data previously, you may wish to pre-emptively adjust any affected entries or perhaps label them for quick identification in future. Most people can just wait and see what happens and return to this announcement for reference in the unlikely event that the new behaviour causes confusion or undesired behaviour.
If an entry in your database source contains form fields with more than one different positive page number these will be treated as different entries. All pages less than or equal to zero will be treated as a single separate page, unless there is only one positive page number in which case all fields will be grouped together into a single entry just as per current behaviour.
This means that for the first time, there will not be a direct one to one link between the entries Kee presents and the entries within your vault or KeePass database. Kee will essentially be presenting “virtual” entries to you. Improved multi-stage sign-in is currently the only reason for this switch to virtual entries but it may well open up the path to further improvements and enhancements in future.
Automatic fill (and submit) of the correct “virtual Kee entry” will depend entirely on the form field metadata such as id, name and type since all other information will be shared across all entries.
Each Kee entry will be marked in some way to allow you to identify which page’s information will be filled if you select it.
The word “page” has always been used to identify these different groups of form fields; while that was the only sensible choice when developing the first version of Kee over a decade ago I am no longer convinced that’s the correct choice today. If you have any suggestions for how to label these different groupings please join the discussion in this topic.
Of course you can still maintain separate entries in your password source if you want but for those who would like to store all information relating to a website account in one single entry, this new feature will make that easier while ensuring that form matching accuracy remains as high as if the entries were separate in the source.
To support this new way of searching and filling virtual entries, the entry saving interface will be modified such that the “Where to save?” step will look something like this:
The default will be to save a new independent entry to a group as per the current behaviour: