request to improve url matching

mbierman

I have noticed that if I have a url for a server such as http://192.168.0.10:8080 in one password record and http://192.168.0.10:443 in another, 1password won’t recognize the difference and grab the right record automatically. Since a port can often leas to a different website, it would be nice if that was part of the pattern matching to choose a login.

---

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

kaitlyn

Hey @mbierman! You're right, ports aren't part of the matching logic that we use currently. That said, I'd be happy to pass your feedback along and let my team know you'd love to see it in the future. Thanks for sharing your thoughts with me. :chuffed:

ref: dev/projects/customer-feature-requests#31

gilles

I am adding a vote for this. It sounds like it would be easy enough to add the port number as part of url matching. It's always a little disconcerting when the most appropriate login does not appear at the top of the list because 1Password is not port matching.

kaitlyn

Thanks for sharing your feedback as well, @gilles!

mtheos

3rding this.

Different ports are considered cross-domain by browsers, and should absolutely be considered the same way here. It's an improvement for both security and the user experience.

ag_michaelc

Thanks for adding your feedback, @mtheos. :smile:

oCtodur

Aye on a vote for this from me too :)

ag_yaron

Thanks for chiming in @oCtodur :+1:

xantari

Vote for me too!

ag_yaron

:+1:

mbierman

Here is another problem case. Zendesk vanity URLs. Even though each is unique, like “abc.company1.com” and “abc.company2.com” will confuse 1Password and show credentials for the union of sites that use zendesk even though the url visible in the address bar is completely different. Perhaps 1Password magic looks at the IP address instead of the second level domain?

IrQX

I vote too. **Port **is an important part of URL to match.

Also, I left one more suggestion here

ag_yaron

Thanks guys.

@mbierman 1Password always looks to match the base domain, so if all of these logins contain "firewalla.com", they will all show up in suggestions.

mbierman

@ag_yaron To clarify companies A and B use zendesk with vanity URLs. So they each have URLs like, "community.companyA.com" and "support.companyB.com". Strangely I see the logins for both in 1Password which isn't ideal.

ag_yaron

That's interesting @mbierman .
Are these public links that you can post here? If not, would you be able to send them over privately via email?

mbierman

@ag_yaron, o.k. So I had a closer look. In all cases, it seems that some interaction had created multiple URLs associated with zendesk powered portals in 1Password. I don't know what triggered that, but that explains what was happening. I'l watch to see if those URLs were really needed in the first place.

ag_yaron

Thanks for the update @mbierman !

You can try saving a new test login on one of these login pages and see if there are two URLs saved in the new login item.
If not, then try to keep an eye on things and notice if/when it happens again and how you triggered it.

We'll be here if you require further assistance with this.

mbierman

@ag_yaron I have an update.

At least some zendesk customers use iframes to login to their community pages. https://help.firewalla.com/hc/en-us/articles/360049896733 is an example. Therefore, when I have firewalla.com or help.firewalla.com as the URLs 1password will fail. However, adding:

works. Now there is nothing I would have seen to "get" that without looking at the source of the page. 1Password should consider looking into how to solve this in a friendly way.

Note, now that I have set that, if I go to zendesk.com I see both my firewalla and Zendesk credentials. Thus, back to where I started. Perhaps Subdomains should be considered in the matching magic after-all? Or users should be able to override the default?

Zendesk is pretty common. I am sure there are other services that fall into this iframe trap too though.

ag_michaelc

Hey @mbierman. Thanks for the update. :smile: If you save a login directly from where you actually sign in, 1Password should capture the necessary URL (i.e., the iframe information). I just tested this on the help link you provided and this was the login saved:

Taking into account subdomains, in particular for services like Zendesk, is something I'll make sure we at least think about, but of course I can't make any promises on that until it's actually in the product. In the case of the iOS screenshot you provided a bit ago, it's currently not possible to match by subdomain in that UI. However, if you click the "1Password" option at the end, you'll see those logins in actual 1Password UI, with a bit more detail, including showing the subdomain, which may help.

mbierman

Thanks @ag_michaelc. That explains a lot. This started because I was seeing multiple logins that weren't appropriate. (e.g. go to zendesk and see firewalla as examples). based on an earlier comment/suggestion I removed them. Sure enough, zendesk was happy because I only saw the appropriate login. But then I wasn't able to login on Firewalla.

So there doesn't seem to be a way to say *.secondleveldomain or "xxx.secondleveldomain" specifically. Those are two very different use cases. I hope that makes sense.

ag_michaelc

Hey @mbierman. I'm happy I could clear things up a bit. :smile:

So there doesn't seem to be a way to say *.secondleveldomain or "xxx.secondleveldomain" specifically. Those are two very different use cases. I hope that makes sense.

Logins that match on domain is the short of it currently. It's not currently possible to restrict logins for a subdomain to show only on a subdomain, nor is it possible to use a wildcard like that to say that a login should be valid on all subdomains (but not the domain itself). Does that answer the question you have at this point in time (I'm not 100% what the question in there was, but I know there was a question)?

mbierman

@ag_michaelc Understood, but I think these use cases highlight areas for improvement. Currently there is no good answer for these use cases. It would be wonderful to see these solved in a future 1Password release along with the original request of this post which is including port numbers.

Thanks for the time, energy, and thoughtfulness.

ag_michaelc

You're very welcome! And understood — while I can't make promises as to how/if this request will come to fruition, the request as filed is more general so we think about it from all angles; it's "bring advanced matching logic, including by port, subdomain, path, etc." :smile: Cheers!