keepassxc-browser icon indicating copy to clipboard operation
keepassxc-browser copied to clipboard

feat: change timeout behaviour for new connections to the proxy

Open WhyNotHugo opened this issue 3 years ago • 4 comments

I've written some changes to the proxy here: https://github.com/varjolintu/keepassxc-proxy-rust/pull/11

Basically, if the socket does not exist, the proxy stays alive, and waits for it, blocking until the socket appears.

This kinda of works -- the problem I'm hitting is that the keepassxc-browser sets a short timeout, and drops the onMessage event listener. When the socket later appears, the pending message is delivered to it, it sends the reply, but that is not handled by keepassxc-browser (because the onMessage listener got dropped). When I later click on keepassxc-browser's UI and tell it to reconnect, it tries to do so, but, at this point, the communication is out-of-sync.

Expected Behavior

  • keepassxc-browser should listen for messages on outgoing connections until they are dropped.
  • The timeout should be reflected on the UI, but if/when a response arrives past the timeout, update the tab icon and state reflected the UI.

Current Behavior

  • I need to kill the proxy, and then retry via the UI.

Debug info

KeePassXC: 2.7.1-1 KeePassXC-Browser: 1.7.12 Operating system: Linux Browser: Firefox

WhyNotHugo avatar Jun 09 '22 17:06 WhyNotHugo

I already have a code like this that should work. Basically it only creates the proxy when the browser is started. After that it assumes the proxy is open all the time and it sends a reconnect command to it which tries to connect to the KeePassXC's socket. So the Reload button only sends that if the proxy is alive.

I'll make a separate branch for it soon.

varjolintu avatar Jun 09 '22 18:06 varjolintu

This all makes sense. When the proxy dies it should only be created after user intervention. Otherwise, it's too easy to start thrashing.

Reload button only sends that if the proxy is alive.

Or starts the proxy otherwise? I believe a service manager cannot handle the lifetime of the proxy because Firefox will only talk to it via stdin/stdout, so Firefox needs to be the parent.

WhyNotHugo avatar Jun 09 '22 18:06 WhyNotHugo

Or starts the proxy otherwise? I believe a service manager cannot handle the lifetime of the proxy because Firefox will only talk to it via stdin/stdout, so Firefox needs to be the parent.

Yes, the proxy should be started otherwise. I need to check it actually works. It has been a while since I tested it.

varjolintu avatar Jun 09 '22 18:06 varjolintu

I'm happy to see we've been thinking in the same direction.

WhyNotHugo avatar Jun 09 '22 18:06 WhyNotHugo