Wait for socket to be created #11
Conversation
|
My intent is to work on the changes required on the browser extension side, but that will likely not be soon. |
WhyNotHugo
force-pushed
the
wait-for-socket
branch
from
a58413e to
0bf550b
Compare
|
The best solution for the proxy should be that it's always open as long as the browser instance is open. And the proxy should handle detecting the socket KeePassXC creates, and makes a new connection if KeePassXC is exited and restarted. I've tried to implement that kind of proxy for a while but I always run to some strange problems with it. This kind of proxy would also solve the problems we have with Automatic Reconnect. |
|
Yup, that's pretty much my reasoning. This PR has the minimal changes required on the proxy side, but the browser extension needs some work (basically, it should not time out; the proxy might respond to the message hours later, when KP is started). |
|
Oh, automatic reconnect is not done here yet either. I've removed most of the |
|
Gotta keep in mind the backwards compatibility also in the extension when we are modifying the proxies. Hah, I wish I had thought things more thoroughly five years ago. |
I'm currently using the proxy with this patch, but the regular upstream extension. It seems to be backwards compatible so far. |
WhyNotHugo
force-pushed
the
wait-for-socket
branch
from
0bf550b to
198946d
Compare
|
Sorry for the long delay. This branch should be helpful for testing this: https://github.com/keepassxreboot/keepassxc-browser/tree/expect_permanent_proxy |
If the socket does not exist at startup, wait for it to be created, and connect to it as soon as it is created. This works in that using it with Firefox and the browser extension works fine. But it does not improve the experience: the extension has a timeout, and if there's no response during before that, it assumes failure and un-registers the response listener. Therefore, when the socket later appears, its response isn't handled properly by the extension. For this to **really** make a difference, the browser extension should not assume that the proxy has exited on timeout, and it should keep the response listener connected. By doing so, when the socket is created at any later time, the proxy will connect automatically, and the browser extension would get a valid response, switching to a "ready" state without the requiring any user intervention.
WhyNotHugo
force-pushed
the
wait-for-socket
branch
from
198946d to
d13b1b3
Compare
If the socket does not exist at startup, wait for it to be created, and connect to it as soon as it is created.
This works but does not work. It works in that using it with Firefox and the browser extension work fine. But it does not improve the experience: the extension has a timeout, and if there's no response during before that, it assumes failure. Therefore, when the socket later appears, this isn't handled immediately by the extension.
For this to really make a difference, the browser extension should not assume that the proxy has exited on timeout, and it should keep the response listener alive. By doing so, when the socket is created at any later time, the proxy will connect automatically, and the browser extension would get a valid response, switching to a "ready" state without the requiring any user intervention.