Keepassxc-browser: You have to click "Reconnect" two times for the connection to be established

[rugk]

Steps to Reproduce (for bugs)

1. Start browser.
2. Start KeePassXC.
3. Click "Reconnect".

Expected Behavior

Only need to click "Reconnect" one time, i.e. after this one click the next time you open the popup it shows you "Redetect credential fields".

Current Behavior

The next time you open the popup it still shows you "Reconnect". You click another time.
Only then the connection seems to be established and you see "Redetect credential fields".

Debug info

KeePassXC-Browser Version: 1.0.1
KeePassXC Version: 2.3.1
Operating system: Linux
Browser: Firefox 59
Proxy used: yes

[varjolintu]

Can you check the keepassxc-proxy process is launched when you click the Reload button for the first time?

[rugk]

AFAIk yes. AFAIk the issue is just that connecting takes so much time.

1. I click the button.
2. I have to wait 2 or 3 seconds.
3. Connection established.

So, IMHO, I was just to hurried and clicked the button another time in the loading time, while the first click already triggered the loading.
So this just sounds like a bad UX issue, where the user can trigger the action another time, when already triggered.

So it already works at the first click. You just should not have the chance to click another time.

Maybe that is also what is causing https://github.com/keepassxreboot/keepassxc-browser/issues/102 or https://github.com/keepassxreboot/keepassxc-browser/issues/93 sometimes, as I doubt it is good to click that button two times.

[varjolintu]

I'm going to investigate this soon and see if there's any stupid delays somewhere.

[rugk]

At least there could be a loading indicator or so, while the process is running, so I cannot even click it twice.

[varjolintu]

True. All this might happen because everything was made asynchronous in the early phase of the extension.

[rugk]

That's good AFAIK, you just need some good indicator support (enable/disable indicator etc.) and so on.

[varjolintu]

Some timeouts reduced with this PR:https://github.com/keepassxreboot/keepassxc-browser/pull/104

[rugk]

Hmm, okay. Still, this does not solve the problem of a missing "loading UI" after clicking "reconnect".
Btw the term is "reconnect", not "reload" as I originally stated.

[rugk]

IMHO the timeouts may not be bad/too long. (Would also be bad, when the connection fails just because something is slow.) It just needs a proper UI.

[varjolintu]

Actually I have problems to get the status to a point a Reconnect button even appears.. testing it when possible.

[mehrdadn]

I've had a somewhat similar problem. If I'm not already connected to the database (which I very much don't want to be forced to do in every browsing session, given that it requires me to unlock the database every time), attempting to auto-fill a field fails silently, so I have to click the icon and then click Reconnect. After doing that, KeePass suddenly asks me to enter a name for the new key (which is bogus because it's already associated with the extension). So I just close that window without entering anything and then refresh the browser. This time around, auto-fill works correctly.

I don't know if that is related to this issue, but it may be. I also don't know what the proper fix is, but I managed to "fix" it by modifying the following two lines of code:

• Setting keepass.associated.value = true here if successful.

• Adding && oldDatabaseHash != 'no-hash' to this condition (this may be wrong, but it works for me)

[varjolintu]

@mehrdadn A new version is released today or tomorrow. Let's see if it fixes for you before I'm doing any changes.

[varjolintu]

@mehrdadn But please test the current develop branch manually if you can. It's the version to be released. If there's really something wrong I have still time to fix it for the official release :)

[mehrdadn]

@varjolintu Oh, the problem is still there on the develop branch (I just tested again right now).

[varjolintu]

If you are already connected to the database there shouldn't be a Reconnect button seen, but Reopen database. Setting keepass.associated.value = true when getting a database hash is not something we want to do. Hash can be received without the browser being associated.

I cannot reproduce the issue so could you tell exactly the steps you do to make this happen? Including the order when KeePassXC is opened etc. Also, please tell you OS and KeePassXC version.

[mehrdadn]

Sorry, by "Reconnect" I meant "Connect". Here's a video of another example. In this video, KeePass (not KeePassXC) is already open and unlocked before the extension starts running. I reload the extension and refresh the page, then start the video.

[varjolintu]

@mehrdadn I'm pretty sure your problem is caused by https://github.com/smorks/keepassnatmsg. I suggest you try to do the same with plain KeePassXC and see if it works.

[mehrdadn]

Hmm okay let me try it and get back to you, I don't have KeePassXC ready so I'll have to set up an environment first.

[mehrdadn]

After _intense_ pain setting this up*, it seems you're right that I cannot reproduce the issue with KeePassXC. I can't really tell if it's a problem technically on keepassnatmsg's side or on this extension's side, though I presume you're correct about that too. But I don't know what the problem could be because I had examined the communication before and not noticed anything strange... is one side more loose with the protocol than the other?

Also, given that understanding and setting up native messaging, the proxies, etc. was so painful and confusing for me again *despite the fact that I've already done this with KeePass, I can't imagine what it must be like for a normal user. It was infinitely easier with KeePass + chromeIPass, so I really, really, really, really suggest working on making it easier to use. :-) It was so painful that if it had continued 3 minutes longer I would have probably completely given up on trying to get back to you!

[varjolintu]

@mehrdadn This is why we wrote a migration guide. Native messaging makes it a little more complicated. This is why a few additional steps are needed.

If everything works with KeePassXC then there's nothing I can do to make it work better with KeePassNatMsg.

[mehrdadn]

Sorry to take this off-topic, but could I ask why the change to native messaging even happened? I get that native messaging is complicated, but that itself didn't seem necessary as far I could tell as an outsider... what was wrong with the old localhost:19455 approach?

(Edit: And yes, I did see the migration guide actually. It would have been even more painful without that information!)

[varjolintu]

@mehrdadn This old thread has some detailed info why the transition was made. Basically any malicious extension could use your localhost and access it with HTTP. Also the traffic was unencrypted and you could intercept the keys (even if localhost is quite safe). The basic approach is more secure with native messaging.

[mehrdadn]

Okay thanks! I'll reply there.

[varjolintu]

@rugk Do you still have the problem after the latest update?

[rugk]

No, it actually works. That's great! :+1: