Matching of HTTP Auth Entries

Hi all,

I use a (private) website which firstly requires a basic HTTP Auth login to access the site, and then separately a different (form based) login to access parts of the site.

I have been trying to understand Kee’s “HTTP Auth Realm” functionality to see if I can sort my entries so it suggests the correct entry automatically.

It looks like NetworkAuth.ts:64 calls ‘FindLogins’ with the url and the realm.

However, in the RPC: KeePassRPCService.cs:1873 the passed in httpRealm string isn’t used at all and the relevant code blocks starting lines 2026 and 2040 seem to be identical?

When the results gets returned to NetworkAuth.ts, there doesn’t seem to be any use of the realm field.

So it seems like the realm isn’t used at all?

Any thoughts?

Thanks, Chris

It looks like when I had to rewrite that part of KeeFox into Kee I forgot that it was the browser-addon side of things that is responsible for ordering the results to prioritise those with the correct realm. I may be forgetting some details by now but I think that the intention with Kee 2.0 was to retain the same behaviour of KeeFox, which was, at least originally, to include all entries with a matching domain/hostname but order the results by how accurately they match, taking into account other factors such as the realm. This way, the best match (with the correct realm) should be auto-filled but other close matches are available for situations where the realm is changed by the website at some future time.

It looks like that never got implemented in Kee and I can’t see any issues to track the work or code comments to explain why that’s not been done.

I’ll have a think about whether the sort-only approach is the right one before rushing into any implementation - it sounds like this might not actually help your use-case anyway?

You might have more luck with the URL matching control described in the recentish release notes: Release notes - KeePassRPC 1.8.0

PS: Sorry about that KeePassRPCService.cs code - there is no reason for that to be two different loops since they are supposed to be doing the same thing (ignoring the realm entirely so that Kee can make the decision at a later date). I have to keep the realm parameter for backwards compatibility but it should be made a lot clearer what’s going on there - I probably modified two loops that used to do something different over many years and never noticed that they ended up the same!


Thanks for the reply.

Essentially my use case is two identical urls and I want a different entry for an HTTP Auth request vs a web form request. I realise this is pretty unusual, I had just hoped there was a way of marking an entry as a HTTP Auth one. Or in other words, if realm matching increased the scoring by +10, I would have the web form entry weighted up +5 and Kee would always suggest / autofill the correct one.

So are you essentially saying that NetworkAuth.ts should sort / score / prioritise the results rather than the RPC? And that that code is entirely missing?

Presumably that code exists elsewhere for the form filling?

On the plus side, now I’ve realised the NetworkAuth code doesn’t use the priorities, upping my web-form entry priority means that one will autofill correctly and I only have to choose on the auth one!

Thanks, Chris

That’s right.

There is code for prioritisation yes, but there’s more-or-less no overlap with what is needed for Network Auth. For example, things like form field id and name matching play a part for web forms.

You should be able to get the web form priority right by ensuring that the web form entry has accurate form field information (such as id and name) for the username and password fields. The easiest way to do that is let Kee save the entry for you but if you don’t want to do that, you can edit the form field information directly within the entry, albeit only after inspecting the page source code of the form (fine if you’re technical - if not, see what I said about getting Kee to save it again as being easier :slight_smile: )

Manually setting the priority field is another possible semi-workaround, as you say but honestly I’m not that comfortable with the feature (it’s way too hard to use it correctly, especially over many years as memories fade) so it might not survive future Kee updates, especially if I can make improvements in other areas to reduce the need for it even more.

I’ve not tested this (and can’t promise it will work in the long-run so don’t go overboard spending lots of time on the configuration of many entries) but you might be able affect the order of the Network Auth results by using the KeePass entry ordering feature. So if you have the Network Auth entry higher up in the list of entries in KeePass but more accurate form field matching on the web form entry lower down the list you could get both working as you want.