Add ability to search all entries, not just those with a URL.

[dlech]

This is a spin off of some discussion in #483

@dlech says (with regard to the new feature of updating existing entries):

Ideally, you should be able to search all entries in the database so that you can update any existing entry.

@luckyrat replies:

Yeah that isn't how it works at the moment but I've been contemplating a change so that KeePassRPC returns all entries and we just filter out the ones without URLs in KeeFox at the points where URLs are required (primarily the list of logins and main panel search results). It's been a low priority until recently but with the new update functionality we definitely have another good reason to investigate the impact of that change.

I imagined the update password feature would be most used by people updating passwords that they had already saved (or at least used) through KeeFox so the lack of entries without URLs shouldn't be a problem for that (majority?) use-case. But easing the assignment of URLs to pre-existing KeePass entries is certainly a valid thing to try to do with the feature so it's definitely worth thinking if we can enable that use-case too.

[luckyrat]

@dlech Do you think this is something you'd be able to look into implementing?

I'd like the no-URL entries to be limited to appearing only after a search via a 3rd "All entries" filter. That filter should only be displayed in the update passwords search interface (not the main panel interface).

The area of KeePassRPC that needs modifying might be as simple as this line https://github.com/luckyrat/KeeFox/blob/4a96d6a2b2c552ec0c85f0908bab4cb8b1fd1eae/KeePassRPC/KeePassRPCService.cs#L1786 but I expect removing that line will result in knock on effects where we conflict with assumptions about a URL existing for every entry (maybe in KeePassRPC but more likely KeeFox).

Maybe at a later point we can consider if/how we would like to expose the entries via the main search interface or list of all logins (it's likely to require some kind of "disabled" state for the entries to prevent one-click login interactions).

[dlech]

Sure, I'll give it a try.

[photonometric]

I always just used FF fmanager and KeePass for reference, so I don't have the URL filled out on any of my hundreds of site entries.

So. To Get the program to update an entry after logging in, which is needed to fill in the string fields and establish basic functionality, I have to manually find the login URL domain, manually find the entry I want to change in KeePass, enter the URL, return to the browser and login, then elect to update the entry.

So, this feature assumes that everyone will already have the very optional information they need to update a site,which is a huge mistake in terms of accuracy and in making a critical feature so excessively, singularly narrow and dependent on a database that is already complete and accurate.

I've skimmed through all the issues, and if nothing is catastrophically broken, this should be your one priority until it is finished. The circular process of filling in information so I can return to a program that had had the information right there in the first place is absolutely ludicrous, and I'm not going to spend an entire day doing it.

Furthermore, unless everyone is on hiatus, I see no reason it still hasn't been addressed after...10 months? For the search, give us anything. Un-tick a box for URL only. allow @name or name: modifiers like in database queries, since there'd only be one at once. Give us a precise regex pattern to search for a specific word in a specific field. Christ, just remove the restriction entirely. It's not like site names and URLs are going to flood the scroll able box on each search.

I'm sorry to be so emphatic. I just gave up my firefox integration based on the claims and recommendations about this program, and I either have to kill the rest of my day to make passwords convenient again, or switch back to FF or keepasshttps. So I thought a little pepper might clue you in about how aggravating this feature is for the people it affects....

[luckyrat]

@chronometric I agree that this would be a nice feature to add and it's useful to know that you feel that it's a high priority for you but I'm possibly missing the bit about why this is such a critical problem for you because it sounds like you have always kept the URL information (in Firefox) separate from the password information (in KeePass), necessitating a manual inspection of both locations each time you log in. Surely having to do that just once more with an additional copy/paste operation to update the URL field in KeePass is not an insurmountable imposition? It doesn't sound like there is any need for you to spend an entire day going through every entry - just spend 30 seconds doing each one as you come across it.

[henryptung]

@luckyrat:

it sounds like you have always kept the URL information (in Firefox) separate from the password information (in KeePass), necessitating a manual inspection of both locations each time you log in

I think the problem at hand isn't that @chronometric wants the account to be separate - it's quite clear they want the account properly bound and usable directly in KeeFox. For preexisting KeePass entries, it's currently necessary to circle back and open KeePass to accomplish this - this runs counter to what I'd consider the mission of the integration (to make normal interactions possible without opening KeePass directly). Of course, "normal" is subjective, but folks have a lot of different devices/browsers/accounts these days; I don't find gluing a web account to an existing set of account credentials a surprising thing. Sure, a 30 second workaround doesn't sound very costly, except that the interaction (intuitively) costs about 2-3 seconds with the right UI; I think that's what's grating on us as users.

Personally, I'd like to add a few usability notes:

• For users that don't necessarily keep their KeePass version fully up-to-date, some functions of KeeFox (like Update existing entry) silently fail, updating e.g. the favicon but not the URL. Not necessarily a critical thing, but some kind of compatibility warning seems merited here.
• Autolock makes the workaround (open up KeePass, log in "manually", then get KeeFox to recognize the new login on the existing entry) extra frustrating, since my KeePass autolocks after I copy the password, which suppresses KeeFox's prompt. While I appreciate KeeFox's functionality, I'm not going to take the extra time out of what I'm doing to log out, then back in just to get KeeFox to pick it up - this means I'll run into the same problem again next time, with potentially the same result.

I'd personally recommend a help-wanted tag or something of the sort for issues you or other folks don't personally plan on implementing (unless @dlech can come back and tell us about how it's gone so far). Though, for GitHub issues, it is super-easy to have no triage workflow; one of its fatal flaws, IMO.

[dlech]

I haven't got anywhere on this. :disappointed:

I think it is safe to assume that all issues on KeeFox are help-wanted.

[henryptung]

@dlech No worries, good to know. Yeah, I guess any unassigned issue is fair game; will see if I can take a stab this weekend.

[photonometric]

I think the problem at hand isn't that @chronometric wants the account to be separate - it's quite clear they want the account properly bound and usable directly in KeeFox. For preexisting KeePass entries, it's currently necessary to circle back and open KeePass to accomplish this - this runs counter to what I'd consider the mission of the integration (to make normal interactions possible without opening KeePass directly).

Yes, thanks @henryptung for helping interpret my issue while I wasn't around. I was not leaving the URL out of KeePass conscientiously; I ran the program for years without needing them there (I have an excellent and much more sophisticated bookmark system in my browser), so I only entered websites into KeePass when I thought I might forget it somehow.

It's not that it's particularly difficult to go back and enter all the URLs in accurately, or even that it would be the longest trivial computer task I've done by hand in years. As Henry once again identified, it feels so frustrating because that's what I got KeeFox for in the first place. But there's a search function right there that is unable to search in one extra field of a simple database. So I go to keepass and probably use the search field there to find the site among my folders and long lists, enter the login URL and then go back to the browser to enter the logins manually, even though it now has all relevant info. Then maybe back to keepass a few times if I'm trying to automate it. Then I wait until the next time I visit the site to see if the plugin is working correctly there.

The port Keepass2Android gets it perfectly right, even while juggling the awkward fake keyboard with its own buttons to avoid the insecure clipboard. If I'm at a site, I hit the program button and search for the name OR URL, and on finding it am brought back to the site to enter it manually or with a single keypress.

It's critical because it's so close to being perfect, but instead is hugely frustrating. I see no reason why I shouldn't be able to search for the name field, even if I needed to use a colon to identify it, and since I'm on the webpage with KeeFox open and communicating with Keepass, there's no reason why it shouldn't enter the URL for me, and with a little sophistication, enter the auto-type sequence I use. Instead we get the exact opposite, and I circle around the two programs two or three times entering information manually that should be part of KeeFox's raison d'etre.

I apologize again for being so confrontational and emphatic, but after setting up a plugin with a very steep and somewhat awkward learning curve, realizing I'm going to act as a database conduit like the encrypted one I just set up is incredibly frustrating, with the only apparent solutiion being accepting the jarring stop to my workflow at each new site and feeling like a search would be just wonderful here :+1:

[cypressious]

Just found this discussion after having the same issue. As a new user I was really confused why KeeFox was unable to find any of my saved passwords. I finally figured out that it was the missing URL field. I must say, this is a very serious UX limitation. I assume there are many more people that have a big KeePass safe full of entires without URLs and this issue is hindering adoption a lot. That's why I agree with @chronometric that his issue should have a high priority. I installed this plugin to avoid switching to the KeePass window when entering passwords but now I have to do just that because the search functionality simply fails for me.

For the sake of all the parents who use their pets name as every password, please fix this so we can help them transition to a system that is both secure and easy to use. Because as we know, security without usability is worthless.

[github-actions[bot]]

Following the recent announcement of the end of critical security patch support for this old software - https://forum.kee.pm/t/keefox-critical-security-support-ends-30th-september-2020-kee-is-unaffected/3219 - this issue has been automatically marked as stale. We will soon close this issue and then archive this repository in early October 2020.

If you think that the issue contents may still be relevant to the actively maintained Kee project, the successor of KeeFox, please search the community forum for help and post a new topic if appropriate: https://forum.kee.pm

Please do not reply to this comment / notification - it won't be seen.