search

keepassxreboot / keepassxc

KeePassXC is a cross-platform community-driven port of the Windows application “Keepass Password Safe”.
https://keepassxc.org/
Other
20.95k stars 1.45k forks source link

Allow Custom plugin data to be editable #2975

Open sebast889 opened 5 years ago

sebast889 commented 5 years ago

Previously as attributes browser/plugin data used to be editable which made it possible to add multiple URLs to allow and deny to the websites that needed it without the need to visit each URL one by one and accepting or denying them individually.

droidmonkey commented 5 years ago

The point of custom plugin data is that we do not want a human to edit it. This is better handled by a dedicated UI element.

Eothred commented 5 years ago

I accidentally hit deny instead of accept after ticking "remember decision" in the firefox plugin (I blame it on not enough coffee this morning). How is it intended that I would fix this then? Delete the plugin entry entirely and start over?

droidmonkey commented 5 years ago

It is very easy to remove settings stored by a plugin. Just edit the entry that you are concerned with and:

image

Phidica commented 5 years ago

I hope this is not considered to be the long term solution. The user then has to revisit all the sites besides the one they wished to remove in order to re-allow or re-deny them as needed. What if the entry is a single sign on that has many subdomains it works on, but others where it shouldn't be suggested? These must all be added back to the entry manually. Clearing the entire property is a frustrating solution in this case.

droidmonkey commented 5 years ago

As stated above: "This is better handled by a dedicated UI element."

Phidica commented 5 years ago

Well, until such a thing exists, can we make the properties directly editable then? Otherwise this is just a restrictive step back from the old method where the user could edit the data as needed.

zpieslak commented 5 years ago

@droidmonkey How can we correct / edit a domain whitelist via browser plugin if it is not possible in the main app ?

droidmonkey commented 5 years ago

We are building that functionality right now, see #3444

DrIT2016 commented 4 years ago

I have same issue, very frustrating to start all over again when only one site (of many) in the allowed/denied list needs to be changed/removed. That new setting of #3444 does not solve this specific issue?

Also there is/was issue with ask dialog when multiple site are matched. You want to deny for one, and the other allow. But when remember decision for one, it also sets it for the other. Could not fix myself, because of no edit possibility.

pfoo commented 4 years ago

As stated before, I see at least two missing functionalities in my use case :

0xpr03 commented 4 years ago

Just had this issue, after 2.5.1 upgrade got asked for ~12 entres on a SSO page. Accidentally allowed them, now had to go through each entry and remove it. Even if we allow this to be edited, we need a much better solution in light of #3779

molusk commented 4 years ago

Same issue here. Not being able to edit (whatever the way is) is really annoying with SSO...

And the result of it and not being able to allow one entry and deny all the others is simply always having either the popup (and then clicking to fast on the bad button, some times with the remember option ticked) or dozens of proposed credentials in the username field. Both cases are really unpleasant.

0xpr03 commented 4 years ago

Yeah I also now only had the choice to disable the stuff for all 12 credentials and go with auto-type.

minus7 commented 4 years ago

Having a simple UI in the browser extension makes sense for most users. But it also makes sense to let a power user edit this data by hand. In many other programs the same could be achieved by the user editing a text file, but that's impossible with KDBX databases. Having the text field editable (even if it requires enabling some kind of advanced mode) seems like a practical and reasonable solution to a problem that quite a few people have.

shoeper commented 3 years ago

This is really annoying. And especially for KeePassXC removing the entry is really bad. It triggers up to many dialogs in the future depending on how many allow / deny entries there were.

michallipka commented 2 years ago

what else to say... +1

bhujagendra-ishaya commented 2 years ago

We are building that functionality right now, see #3444

Hi @droidmonkey

A few years later, we're still stuck with that. #3444 has been merged, with the functionality of editing the allow and deny options still missing in version 2.7.1.

Is there anything we can help to implement this? - I'm not sure I have the programing skills to do it myself. But happy to give it a go if you could point me in the right direction ....

Thank you for all the great work, Bhujagendra.

droidmonkey commented 2 years ago

It's a somewhat niche request and will require a fair amount of gui ninja skills without letting people modify the custom data directly.

bhujagendra-ishaya commented 2 years ago

I appreciate that you decided to not have the option to edit the plugin data entries in the properties section. But would it not be possible to edit the value of the KeePassXC-Browser Settings key just as plain text JSON string on the Browser Integration tab? I guess that would be quick and dirty but would give the users the functionality they used to have - and I'm using it quite frequently, particularly after cloning an entry.

Also, it is not 100% logic that you do not allow to edit plugin data anymore whereas the advanced properties KP2A_URL* are still editable both on the Browser Integration tab as well as manually in the Advanced tab.

Furthermore - but this would be a different feature request - why are not the hostnames that are listed in the KP2A_URL* entries automatically allowed? I mean, why would anyone want to add it there and then deny access to it? This auto-allow could be restricted to the actual FQDNs used in the KP2A_URL*: so while an entry with a host example.com is also suggested/used to the user for host.example.com, this would not be the case in the auto-allow scenario. There only requests for the exact match would be considered. Otherwise the user is asked, if there is no specific deny/allow entry.

droidmonkey commented 2 years ago

We default to "ask" for urls not explicitly allowed or denied. You can turn this off of course in the browser integration settings at the application level, in which case we default to allow unless denied. We could also allow editing this in our new browser integration report under the database reports feature. That, to me, makes the most sense and allows for a wholistic view across the database as well.

rjcanis commented 8 months ago

Has there been any movement on this?

Real world use just so you know, I have https://mycompany.com in my database, and I have about 20 servers that all use that same entry some are xyz.company.com, and abc.company.com, etc. I have one that is 123.company.com that needs to have its own entry because of TOTP. I can do that, but now I have two entries when I got to select this site. I'd like to remove 123 from my plugin data browser settings value but not screw up the other 19.

Thanks all.

varjolintu commented 8 months ago

Has there been any movement on this?

It's on my very long TODO list.

ecspresso commented 5 months ago

Has there been any movement on this?

It's on my very long TODO list.

Can you point us at which file to start looking at, so that someone from this issue (me for example) could look at it perhaps?

droidmonkey commented 5 months ago

https://github.com/keepassxreboot/keepassxc/blob/develop/src%2Fgui%2FEditWidgetProperties.cpp