first of all thank you for your helpful instructions! Using form or field id’s or names in the whitelist or blacklist works pretty well.
Jobwise I have to login to lots of websites based on content management systems the ones of which contain lots of forms for all kinds of options and settings. I experimented with different options on Kee’s URL panel within KeePass to prevent Kee from mingling with every form it finds - to no avail. So your suggestion helped me a lot, only there are a lot of form/field id’s I have to blacklist.
Wouldn’t it be much easier if Kee would offer an option to ignore the current form or field (provided Kee finds a respective id or name) in that field entry menu like so …
… and automatically add the form/field id/name to the blacklist?
I have seen lot of issues about blacklists but I think whitelists are very important tools too. It would be really nice to detect the name or id of the field without looking at the browser inspector directly (as an option in Kee to add the fields id in the whitelist). Editing the whitelist is indeed quite painful because everything is on the same line.
Some details are also hard to find like no space after comma (once you know, it works really well but I did not undertand why it was not working before I found this).
I was wondering if it was possible to fill the fields specified in KeePassRPC automatically without using whitelist, there are case where you need to specified the field in whitelist to have the Kee logo in it, this is not expected by the average user I would say. But I think you talked about a related security issue ?
The typical use case of whitelist is the one in this issue (google TOTP) : https://github.com/kee-org/keepassrpc/issues/45 . I think it deserves a place in the documentation of whitelists (the screenshots of pyro-dev are really nice) because you are confronted to it as soon as you activate 2FA.
I agree that it’s worth linking the concepts of placeholders and whitelisting because Kee will only attempt to fill in forms it’s reasonably sure are username or password fields (TOTP fields therefore are often ignored when not part of a single username/password form). I’ve added a note to this effect in the placeholder documentation.
Developing a more user-friendly way to manage the lists is something I’ve wanted to do for as long as the feature has existed but have yet to have enough time to work on it. It’s a case of having the feature at all being better than no ability to override the behaviour but I know it’s a very involved process, especially for people with little technical knowledge.
I guess you added the condition of having a username/password in the form to activate Kee because it would fill any field in any page elsewhere. The note on TOTP in placeholder documentation is very helping by the way.
To manage the lists I would say that optimally, Kee should fill the forms as soon as there is a corresponding entry for the webpage and one of the field name or id specified in the KeePassRPC tab appears in it. It solves the current problem which is that you have to write the field name/id two times : in KeePassRPC and in Kee whitelist. According to me, if you write it in KeePassRPC and enable placeholder it somehow means that the user is already aware about security issues and rare bad filling attempts. Maybe you can find a security issue in my argument because I am not really well aware of everything.
Also, it could be very nice to have a field selector as in KeePassHttp to complete the KeePassRPC without the inspector (but yeah, lot of work, it can wait)
I bet all of this is a really big work given the time you have and that maybe you have to rewrite some core part of Kee. So if you lack of time, maybe you can improve the presentation of whitelist in Kee for now.
I think that you should use a textbox rather than just a big line to show what fields are in the list, we can’t see currently entirely the whitelist in one look it is really annoying.
You can index the list with the output of the field : one whitelist for username, one for password, one for otp … without changing anything in the current field management ! It just allow to structure the different parts and remember what this field is for (in the global whitelist especially).
And you should give the user to add output type as before in the list and filling it with the good fields name/id.
Hello, let me dig up this old thread because github told me I should not open an issue there before posting in the forum.
I think it would be really useful to have a button or context menu entry to put input fields/forms on the blacklist (or whitelist). Having to inspect the text field and then add the exact right value in some hidden preferences page is a pain in the bum. Just a simple “Add field to blacklist” or “Ignore field” context menu entry that automatically enters these values in the right places would improve the usability of this feature immensely.
