After newest release v2.0.14, all entries prompt

[Skrelpoid]

It seems these 2 points from the release notes are not quite working as intended:

• security fix: if the title or url fields exactly matched the hostname, without the scheme prefix (ie http, https), it would send the credentials without prompting. this has been changed now to always prompt, if it hasn't already been allowed.

• data is now stored in Custom Data, it will prompt you to move your existing settings when opening a db with data in the legacy location.

After the update the plugin said it migrated my data and told me to delete the entry KeePassHttp Settings from my Database.
After I did that some entries still have KeePassHttp Settings as advanced String fields. I'm not sure but I think on some fields it was removed. However, every page prompts for the credentials and asks me to allow it. After saving it that time everything seems to be working for that entry.

But now for each entry it asks again to allow or disallow the autofill which is kind of annoying.

[smorks]

That's definitely strange. I'm guessing the migration didn't work properly? I'll do some investigation on my end here to see I can figure out what went wrong.

[Bond246]

Hello guys,

i have some strange behavior that maybe is related to this one.
My browsers seems randomly want to reconnect to my database.

And today an idea came to me that evertimes i open the database on a different machine it asks for reconnecting. Could that be?

[smorks]

i have some strange behavior that maybe is related to this one. My browsers seems randomly want to reconnect to my database.

And today an idea came to me that evertimes i open the database on a different machine it asks for reconnecting. Could that be?

@Bond246, i believe this is fixed in #85.

@Skrelpoid the issue with all entries prompting appears to be something different, that i'm still looking into. can't seem to reproduce the issue so far though.

[hauk92]

I have the same problem. I think this is caused by having the database synchronised at startup and having a newer database version at the synchronised location. Maybe @Skrelpoid could confirm if he is also doing something like that?

I have managed to recreate the problem with the following steps:

1. Create a new database with an old version of KeePassNatMsg and create entries to be migrated
2. Save the database
3. Synchronise the database to another location and enable synchronisation at startup
4. Backup the database somewhere else
5. Make a change in the database and synchronise it
6. Restore the older backup database and upgrade KeePassNatMsg
7. Open the database and confirm the migration prompt

After this I end up with correct plugin data in the database (KeePassNatMsg_Migrated and KeePassNatMsgDbKey entries), but the data in the normal login entries is not migrated (I do not think any KeePassHttp strings are removed but I have not tested this extensively)
I have tried this with local synchronisation and with a google drive plugin, it makes no difference.

Another weird thing is if I delete plugin data entries in Tools>Database Tools>Database Maintenance>Plugin Data and synchronise the database, the entries just get synchronised back into the database. So to delete those I would have to override the database at the synchronised location.
Maybe all of this is a bug in KeePass? @DReichl

A workaround for this issue is to delete KeePassNatMsg_Migrated in Tools>Database Tools>Database Maintenance>Plugin Data (and restore the "KeePassHttp Settings" entry if it was deleted) and restart the migration via Tools>KeePassNatMsg Options>Advanced>Check for Legacy Config.

[Skrelpoid]

I have some synchronizing, but I am not sure about if this is the caus of the issue

[xeropresence]

I'm still getting this with 2.0.15

I tried to narrow down what's happening using a simple domain : accounts.google.com

On version 2.0.13 visiting accounts.google.com does not prompt for access, all entries are displayed.
Some, but not all of the keepass entries have an additional string field containing {"Allow":["https://accounts.google.com"],"Deny":[]}

After upgrading to 2.0.15

Visiting accounts.google.com prompts for access listing every single account, hitting deny yields no approved entries.
The accounts that had additional string field now have the additional plugin data with the same content of {"Allow":["https://accounts.google.com"],"Deny":[]}

Title for all entries is accounts.google.com
Url for all entries is https://accounts.google.com/

Changing title and/or url has no effect on if account is approved.

If I revisit accounts.google.com and approve the request, and check the box to remember this decision all entries for the site get updated to have the plugin data of {"Allow":["accounts.google.com"],"Deny":[]}

Visiting the site again yields the expected result of the entries just working without a prompt.

If I revert to a backup, and restore 2.0.13, edit the string field setting to {"Allow":["accounts.google.com"],"Deny":[]} and then upgrade to 2.0.15 the entry that had the edited setting will get approved while all the rest will be rejected when prompted and hitting deny.

This leads me to believe the issue lies with the change of

security fix: if the title or url fields exactly matched the hostname, without the scheme prefix (ie http, https), it would send the credentials without prompting. this has been changed now to always prompt, if it hasn't already been allowed.

as the url correctly matches the requesting domain including the scheme and its still requesting additional confirmation.

I don't use any replication or synchronization to a external location.

@smorks if you need anymore information please let me know

[smorks]

@xeropresence thanks for the detailed information! i will investigate further with the information you provided, it sounds like that security fix is the likely culprit.

[smorks]

i did some testing with this, and can't seem to find an issue.

i created four entries with the same title and url.

upon visiting that url I am prompted to confirm access to all 4.

if i click allow, it shows all 4 in the browser extension. if i reload or open a new tab to the page, it prompts again, as expected, because I didn't check the "Remember this decision" checkbox.

if i click deny, it doesn't show any in the browser extension, and will prompt again the next time i visit the url.

if i click allow, and click the "Remeber this decision" checkbox, it no longer prompts me and shows all 4 entries each time I go to that url.

if I click deny, and also click "Remember this decision", it no longer prompts me and doesn't show any entries when visiting that url.

is that the same behavior you're seeing. is there some behavior here that isn't working as you expect? or am i missing something?

[xeropresence]

Prior to version 2.0.14 it wouldn't prompt if the url matched, which is a behavior I expect (and want), but would prompt when accessed from a different subdomain, or when a iframe is used.

#83 Seems to change it to care only about the access list which I think is excessive. I am unsure if the entries are created by the this plugin or if they are created and then just passed thru from KeePassXC-Browser but the default creation does not create an access list (in 2.0.13 at least)

So I am in the current situation where entries that were created by the browser extension no longer work and I must approve their access every time which is cumbersome, and enabling "Always allow access" is undesirable as I do wish to be notified if someone tries to access a sites credentials via iframe or on a subdomain.

I prefer the previous behavior where if a url is supplied then we assume that we want the entry to be sent to the browser.

[smorks]

So I am in the current situation where entries that were created by the browser extension no longer work and I must approve their access every time which is cumbersome, and enabling "Always allow access" is undesirable as I do wish to be notified if someone tries to access a sites credentials via iframe or on a subdomain.

If you click the "Remember this decision" when allowing access, it will only remember for current domain that you're on. So it should continue to prompt when accessed from subdomains other than the one you "Remembered". Isn't that the behavior you would like?

so basically, it just required the one extra step of prompting and "Remembering" the domain you would like, and it should continue to prompt on different subdomains/iframes.

[xeropresence]

So I am in the current situation where entries that were created by the browser extension no longer work and I must approve their access every time which is cumbersome, and enabling "Always allow access" is undesirable as I do wish to be notified if someone tries to access a sites credentials via iframe or on a subdomain.

If you click the "Remember this decision" when allowing access, it will only remember for current domain that you're on. So it should continue to prompt when accessed from subdomains other than the one you "Remembered". Isn't that the behavior you would like?

so basically, it just required the one extra step of prompting and "Remembering" the domain you would like, and it should continue to prompt on different subdomains/iframes.

Yea, but that's extra work and I like how it worked before. Like you said in the comments to #83 it's how KeePassHttp worked, and I expected the same behavior from this.
Now it's 3 extra clicks, 1 for the checkbox, 1 for the allow, and 1 to refocus the window each time I visit a site for the first time.

I haven't tested it, but if new entries aren't created with that accesslist then I'll have to do this extra step for each new site and entry as well.

I think #83 should either be reverted and a scheme check added or the change made optional as I don't enjoy the thought of having to approve 500+ sites over time.

[smorks]

i would rather just add another option to not prompt if the url is an exact match, which should resolve the issue you have.

i will add an enhancement for that.

i will close this issue if you feel that enhancement would meet your needs.