Hi,
I think I found a bug in KeePassRPC.
Keepass Version 2.57 64bit
KeePassRPC 2.0.2
This happens only with KeePassRPC is installed. In the history you see that there is an entry for “KPRPC JSON (+)”
This is not nice 
Best Regards
Indeed, it’s not ideal to see this behaviour and it is something I considered and tested for thoroughly before release so it’s a shame to see it affecting some people now.
Unfortunately I am unable to reproduce the problem so can’t begin to hypothesise what is causing it for you.
If a cause can be identified or a PR created to fix the issue I’d happily release an updated version to remove the annoyance. At the moment, given that I can’t reproduce the issue and there is a workaround (either click Cancel or just save whatever change is being automatically made) it’s not something I can spend a lot of time on myself.
I’ve made this post public in case anyone else can help shed light on the cause or potential fix.
I am also experiencing the same problem.
My first question is: When and also what data is your plugin saving to entries?
Whole JSON-string:
{“version”:2,“authenticationMethods”:[“password”],“matcherConfigs”:[{“matcherType”:“Url”,“urlMatchMethod”:“Domain”}],“fields”:[{“uuid”:“AWV4GM2uc0edKFvlK5ZXag==”,“valuePath”:“UserName”,“page”:1,“type”:“Text”,“matcherConfigs”:[{“matcherType”:“UsernameDefaultHeuristic”}]},{“uuid”:“GXkrZAjADkWzARYCM+Vcdw==”,“valuePath”:“Password”,“page”:1,“type”:“Password”,“matcherConfigs”:[{“matcherType”:“PasswordDefaultHeuristic”}]}]}
The strange thing is: the notification for saving changes is not at every try to close an entry with unsaved “KPRPC JSON (+)”-change…
Same for me, I get the same JSON (only UUIDs are different).
KeePass 2.57, a new database, KeePassRPC is the only installed plugin.
I’ve been seeing this behavior too. In my case I see the KPRPC JSON being moved from “String fields” (Advanced tab) to “Plugin data” (Properties tab). Once I save the entry after this change, if I re-open the entry I’m no longer prompted to save it.
KeePass 2.57.1, definitely NOT a new database, KeePassRPC 2.0.2, couple of other plugins.
In some sense it might be nice to have a migration process that fixes all entries at once, but in practice I don’t know that it’s worth the development time. I can just save entries as I open them.
I am experiencing exactly the same problem.
My configuration is exactly the same as the previous speaker.
I would appreciate a solution.
Best regards
This is an extremely annoying bug. I’m seeing the same behavior.
Upon opening an entry in KeePass, the KeePassRPC plugin, version 2.0.2.0, adds a KPRPC JSON field to the entry, even if the user makes no changes.
Closing the entry with X button or Esc key now prompts “Do you want to save the changes you have made to this entry?”
If you happen to use Esc to close an entry, hitting Esc again on the modal will simply cancel the modal, and you’re back where you started. Hit Esc again, and the modal opens again. A vicious cycle begins that forces you to actively STOP whatever you’re doing and devote your full attention to this nasty dialog by using your mouse to hit the Yes or No button.
And this 10, 20, 30 times every day. This is incredibly disruptive to any kind of workflow, and all because the KeePassRPC plugin now adds some settings data to each entry that you happen to open.
And the developer seems to feign ignorance, or at least be unaware that his testing of the new version, which obviously didn’t include a database with older entries in it that lacked his new field, is totally insufficient.
luckyrat, I really appreciate your work on this plugin, but I hope you can see that this whole thing is hugely frustrating, and simply a no-go in terms of UX.
I don’t claim to be able to solve your architecture decisions for you or know it all better - I respect your "author"ity here - but why do you now want to store metadata about each entry in the first place? It wasn’t necessary before version 2, and that worked flawlessly.
If you’re planning for new features, or already shipped a new feature that requires the metadata, then please, make it opt-in. I for one don’t appreciate you inflating my database with your json string in every.single.entry. I don’t need whatever feature you have cooking that might utilize that.
So please, be transparent and ask the user if they give you permission to write to their database in the first place.
Then, if you got their permission, do a onetime run through all the entries in the database and amend each one with your json. That’s how you prevent that users get this save dialog every time and don’t know where it comes from or why KeePass suddenly behaves this way.
Or, you know, just stop adding new json to my entries and keep the functionality that’s already working perfectly, working perfectly.
Just please don’t simply ship an update that silently amends the json string to all entries that lack it upon install. That would be a serious violation of the trust we place in you, and of your integrity as a security-concious developer of a security companion application.
I will be monitoring this thread closely, and if the apparent ignorance continues, or if there’s a lazy enshittification update that magically “fixes” this by adding 40% to my db size and modifying every entry of MY database without asking me, I will uninstall this, and I’ll advise everyone else to do the same. It will have to go into the ever-growing graveyard of software that had its ethical standards thrown out the window.
I apologize for using such harsh language in some parts above. I’m a bit fired up right now.
Thank you.
As I understand it from earlier comments, you can break this cycle of notifications by accepting the changes and saving your database. Eventually one would expect that the issue would therefore be resolved with this workaround.
I can’t reproduce this problem. I have tried again with different databases, including a brand new one that has no existing KPRPC data within it. As such, there is nothing I can do at this stage to help with any mass/automated migration steps or other adjustments to avoid the modification question being presented.
KPRPC data in each entry is, and always has been, essential for the plugin to work. That won’t change so we need to find how to best store and access that data. As of KPRPC 2, we store the data according to the latest method recommended by KeePass. That is different to the earlier approach so a change in behaviour is not entirely unexpected. There are other topics regarding the how and why of this change so I won’t go into it here.
I appreciate that the workaround is not ideal and there are certain workflows where it would be more inconvenient than others so if we ever identify how to reproduce it and can identify how to prevent it from being required, I’ll happily accept a PR with such a change or work on it myself if time permits.
PS: Regarding the tangential idea of permissions requests, warnings / questions and API-specific access, that’s something that only KeePass itself could offer and enforce (and not without a complete rewrite of the plugin system, and probably a complete rewrite of the application in a different language). I don’t see that happening and despite the potentially interesting improvements in user control and understanding that could bring, I can’t see me advocating for all of that effort - definitely something to contemplate if the application ever gets rewritten from scratch though.
Thanks for your reply. I’ll try to to help narrow this down and make it reproducible.
you can break this cycle of notifications by accepting the changes and saving your database
Yes, separately for each entry, one by one. This is not an insignificant feat for a typical database of several hundreds of entries, and it’s a daunting task for a large one. I don’t think anyone would consider spending many months reorganizing their workflow and muscle memory until all entries have been touched on-the-fly, or potentially spending days going through each entry manually just to open+save them all.
I can’t reproduce this problem. I have tried again with different databases, including a brand new one that has no existing KPRPC data within it.
The issue with with:
a) old databases with existing entries that were added before KPRPC was upgraded to version 2 or installed in the first place. To reproduce, you could try disabling the plugin, adding a couple entries to the database, then enabling the plugin again. Those entries should now lack the new field (since the plugin wasn’t active) and KeePass will prompt to save upon closing an entry.
The issue isn’t with new databases, or with new entries that are added to a database while KPRPC is installed and activated.
b) any database that is used by other apps (e.g. KeyPassDroid) or plugins on devices that don’t have KPRPC installed. When you add an entry to the database on such a system, it won’t have the new field either.
This is a common usage pattern that I believe many people follow (with the mentioned app or another) to synchronize the database across devices, including devices that KPRPC doesn’t support.
I hope this information will help you reproduce the issue.
permissions requests
I understand the nature of KPRPC as an add-on. My comment was not about rewriting the application, but about responsibly making KPRPC get the user’s permission before it adds its own metadata to each entry in the first place. I’ll accept that that’s the topic of a different discussion though.
