Authorize new connection dialog without the browser tab

Kee browser extension
#1

It seems that when there are no browser windows associated with the running extension, the tab to enter the authorization code isn’t spawned. When I deny the request, another one pops up shortly.

I reported this on GitHub in the past (https://github.com/kee-org/browser-addon/issues/243), but let’s also have the issue here for visibility. To be clear, the issue reappeared again just today.

I checked Chrome’s Task Manager with the Profile column shown. There were profile-agnostic processes, both interactive and non-interactive processes from a profile that doesn’t have Kee installed and then only extension processes from the profile that does have Kee installed. It seems one can get this state by opening windows with both profiles and then closing all windows from the one with Kee installed.

  • Chromium 87.0.4280.66 (Official Build) (64-bit)
  • Kee 3.6.27
1 Like
#2

I looked around in kprpcClient.ts for a while, but couldn’t figure out when exactly KPRPC shows the dialog on the side of KeePass, but even with that, the message-based flow doesn’t really lend itself to static analysis without knowing the whole SRP protocol. :slight_smile:

I can try debugging the extension to see what kind of error, if any, shows up, but I have two questions first. To see the error messages, I need to unpack the CRX and load it unpacked, right? To trigger the SRP, I need to revoke the authorization, but then what?

#3

Thanks for offering to delve into this problem in more depth.

The best way to debug the KeePassRPC client (Kee extension) would be to use the debug version of the extension. If you’re using a beta version of Kee then unpacking the crx would give you easy access to the source code for that purpose, or you can download the zip file from the relevant GitHub release page (this would be the zip file that Google then sign as part of the conversion into the crx file). Typically, I would use an unpacked version of the debug (beta) extension which I have built from source on my development machine but if you use an unpacked version that the CD pipeline in GitHub has built and attached to a release, you’ll get the same in-browser experience. In fact, even just using the beta version without unpacking it should work too, although that’s not something I have done very often.

Once you have that working, you can use Chrome’s inspector to debug the extension’s background process and thus see the source code (via the source maps that are included only in the beta version of the extension) as well as interact with the running state via debug breakpoints and logpoints.

The SRP one-time password dialog is triggered in the KeePassRPC plugin when it receives a connection request from Kee and can find no associated shared secret for the unique ID that Kee supplies as the “username” for the SRP connection (broadly speaking). Thus, I expect if detailed debugging of the SRP protocol is required, you would be best off focussing on the C# code in the KeePassRPC GitHub repo.

KeePassRPC technical detail could also contain some useful information without you needing to dive deep into the C# and TypeScript implementation code.

#4

So for future reference, I did this: Installed the beta (after joining the group), copied it (/Extensions/hlicbbodnlbbflfihnjjffnjeaoglici) to another location, uninstalled the beta, enabled developer mode in extensions, loaded the extension from the other location, enabled Collect errors from extension details.

Now, why collect errors instead of developer tools? As long as I had the inspector open, the extension was able to successfully open the SRP tab. I didn’t want to experiment around with other methods how to extract information from the background process, so whatever I needed to extract I just threw in a separate stack, like this:

try {
  const tab = yield browser.tabs.create(createData);
  const p = browser.windows.update(tab.windowId, { focused: true, drawAttention: true });
} catch (err) {
  setTimeout(() => { throw err.message; }, 0);
}

Then in Extensions, I would click the Errors button below the extension and the things would be there
for me to read, although stringified.

SRP was being initiated practically all the time, so I had no issue triggering it. Closing the tab (if it existed) or denying the request on KeePass’s side was enough to get a new one in a second.

Well, no surprise there, the block fails with “No current window”.

Depending on other factors, I see two solutions:

  1. If we don’t have a window, we don’t initiate SRP and wait for some time before checking again (or maybe there’s an event to subscribe to).
  2. If we don’t have a window, we create one first.

I’d prefer the former on the grounds of the principle of least surprise to the user.