Exact Match isn't always, and could be improved

TheDave

I like the Exact Match vs Close Match in the browser extensions, but I feel like this could be improved in two ways.

1) Consider all website URLs, not just the first one in a 1Password entry as candidates for an exact match.

This comes up on all sorts of sites, Stack Exchange is a great example in that I can use one set of credentials across a large number of sites. My Stack Exchange item in 1Password has multiple URLs such as https://stackexchange.com/users/login and https://serverfault.com/users/login, but only the first URL will generate an Exact Match, the rest are Close Matches even though the URL might exactly match my 1Password entry as a secondary website.

Amazon is another prominent example, my accounts for https://www.amazon.ca and https://www.amazon.com are linked and use the same credentials, while https://signin.aws.amazon.com is a different set of credentials. When I login to both amazon.com both this entry and aws.example.com are only a "Close Match" while it should be possible for 1Password to determine which is the exact match by evaluating all the websites listed.

2) When there are multiple Exact Matches, evaluate more of the URL than just the hostname. Or maybe have "URL match" "Hostname Match" "Close Match" categories (or at least, sort in this order, you could combine the first two as "Exact Match" candidates, just put the URL match first).

Imagine I have these three items in 1Password, each with their own URL and credentials:

• https://thedave.example/1 (my CMS)
• https://thedave.example/2 (my photo gallery)
• https://thedave.example/3 (my private pastebin clone)

When I visit https://thedave.example/2/login and click on the 1Password browser extension, all three show up as Exact Matches, but I feel like 1Password could be a bit smarter. I'd suggest first looking for cases where the URL in 1Password exactly matches the start of the current URL, so in this example https://thedave.example/2/login would result in the /2 entry being the only one to be considered an exact match. Second, list any hostname matches (https://thedave.example/) and third list any close matches (https://dev.thedave.example/)

This is a real world issue I run into in a couple places, on my own small company's website my main CMS vs the billing system live in different directories under the same hostname. At $DAYJOB, our intranet has a number of different components such as an internal wiki, various internal tools, internal chat system which all share one common hostname but are located in separate directories and need separate credentials (extra annoyingly this is often just a different username format, dave vs dave@$DAYJOB.example vs $DAYJOB\dave while the password is verified against Active Directory)

Thanks for your consideration, as always!

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

MikeT

Hi @TheDave,

Thanks for reporting this.

Consider all website URLs, not just the first one in a 1Password entry as candidates for an exact match.

This is a known bug, it is supposed to treat all URLs the same but it is not. It'll be fixed in a future update.

2) When there are multiple Exact Matches, evaluate more of the URL than just the hostname

Also a known bug, hostnames are not supported yet, our URL processing library doesn't support hostnames and due to that, it also cannot do comparison without a TLD. It's silly we know but we'll get it fixed.