Wildcard matching on domain names

trailmax

In version 4 I could create accounts for web-addresses with a wildcards: *.example.com. That would match any subdomain - one.example.com, two.example.com, etc. And I have a number of accounts on systems like that.
Now in 1PW7 this feature does not work and Chrome plugin does not find me my passwords on one.example.com.
Can this be restored in v7 please?

---

1Password Version: 7.0.532
Extension Version: Chrome
OS Version: Win10
Sync Type: Dropbox

AGAlumB

@trailmax: Thanks for reaching out. I’m sorry for the confusion! 1Password has never supported wildcards, so they would just be ignored. If you save a login for example.com though that will also work at one.example.com as well. I hope this helps. Be sure to let me know if you have any other questions! :)

trailmax

@brenty AH! that works!... mostly.

It works with one.example.com, two.example.com when website in 1PW record is recorded as example.com. However I have a number of web applications I work on locally, all of them are working under .localhost domain name (from HOSTS file). And that is not recorgnised by 1PW.
I.e. in 1PW I have web-site recorded as myapplication.localhost, but when I go to tenant1.myapplication.localhost, this record is not found in 1PW mini. Not sure if this has something to do with .localhost domain. But this used to work in v4.

MikeT

Hi @trailmax,

That's a separate issue, we do not support local hostnames in 1Password 6/7. Our current URL processor does not read them properly.

We will fix this in a future update but we don't have a timeframe on this.

If you use the IP address instead of the hostname (add it as the first URL field), it will match it.

ref: OPW-954

trailmax

@MikeT That's a shame. It worked just fine in v4. Why does it matter if domain name is pointing to 127.0.0.1 or to 123.123.123.123?

I literally have dozens of *.localhost passwords, all pointing to 127.0.0.1. Even if it matches to the IP, it will still be an effort to pick the one I need. Though I'll give it a try with the IP addresses.

trailmax

@MikeT hm.. Just tried adding 127.0.0.1 as a website and it made zero difference - still can't match tenant1.myapp.localhost to myapp.localhost. Though if I put exact url tenant1.myapp.localhost as a web-address, I hit a match. So your URL processor works with local domain names, but does not like to do a match on subdomain for *.myapplication.localhost.

Sigh. Should I just go back to v4?

AGAlumB

That's a shame. It worked just fine in v4. Why does it matter if domain name is pointing to 127.0.0.1 or to 123.123.123.123?

@trailmax: localhost isn't a domain name. It's just shorthand for 127.0.0.1. I appreciate that you may want it to mean more than that for your use case, and perhaps I would too, but we're not the one's who set the standard.

I literally have dozens of *.localhost passwords, all pointing to 127.0.0.1. Even if it matches to the IP, it will still be an effort to pick the one I need. Though I'll give it a try with the IP addresses.

Correct me if I'm wrong, but since localhost and 127.0.0.1 are literally the same thing, you'd have to pick the one you'd need from a long list anyway.

hm.. Just tried adding 127.0.0.1 as a website and it made zero difference - still can't match tenant1.myapp.localhost to myapp.localhost. Though if I put exact url tenant1.myapp.localhost as a web-address, I hit a match. So your URL processor works with local domain names, but does not like to do a match on subdomain for *.myapplication.localhost.

*.myapplication.localhost is something you made up. localhost is simply shorthand for 127.0.0.1. So it is unlikely that will work for you even when we add support for localhost entries. *.myapplication.localhost is like saying *.myapplication.127.0.0.1, which doesn't make any sense either. localhost is just your local machine, so 1Password would be displaying any saved logins that match that regardless.

Sigh. Should I just go back to v4?

If the beta isn't a good fit for your needs right now, then yes, that may be best. We appreciate your participation and feedback, but if you're expecting to not run into any bugs or limitations you're going to have a bad time.

trailmax

@brenty I should've been more clear. In my HOSTS file I have entries like this:

127.0.0.1 tenant1.myapp.localhost
127.0.0.1 tenant2.myapp.localhost

It used to be

127.0.0.1 tenant1.myapp.dev
127.0.0.1 tenant2.myapp.dev

Then I have IIS running on my machine with a *.myapp.localhost (used to be *.myapp.dev) domain name pointing to an app and it all works in all browsers.

But Google recently bought .dev domain and I had to change it all to be .localhost. So tenant1.myapp.localhost is not translated into tenant1.myapp.127.0.0.1, it is translated into 127.0.0.1.

Is "localhost" word throwing 1PW7 off the tracks? what if I change it to something else, like .local?

As for expecting bugs - yeah, it'll be frustrating. But who is going to complain about stuff that does not work? People don't complain and we end up with mess like the delete button I complained in another thread. So no, I'll stick to the beta :-)

AGAlumB

@trailmax: Thanks for clarifying, and for sticking with the beta. We appreciate your unique perspective, and we'll be making 1Password understand localhost in the future. :)

MikeT

Hi @trailmax,

To expand on Brenty's answer and to answer your last question:

1Password uses Mozilla's public suffix list to find the top level domain, it is hard to be accurate on finding what TLD is between 1Password.com and 1Password.co.uk. If we were to simply parse the last set (.com vs. .uk), it'd look like 1Password would match on UK > CO > 1Password but it won't find anything because technically, it is internally saved as CO.UK > 1Password. There are many custom TLDs as you can find in the public suffix list where a.b.c.d is actually D > C > B > A and not D.C > B > A.

1Password has no idea what custom/internal TLD works, it does not know if it is to match on LOCALHOST > MYAPP or LOCALHOST.MYAPP > tenant1. All it has is the public suffix list at this moment. We have no fallback implemented in 1Password 6-7.

Now, I can answer the other question. 1Password 6 is a clean codebase (on Windows only), it has no reused code from 1Password 4, the only thing it has in common is the product name, 1Password. None of its previous features or behaviors are in 1Password 6 or 7 nor do we even have the same team/tooling working on 1Password 6/7. So, everything is different and has to be re-implemented. In this case, we have no matching code for custom TLDs and certain hostnames.

To be clear, I was referring to hostnames, not TLD as well. You can have 127.0.0.1 a and access http://a.

Now, I should've been clear and explain you need to access the site via its address/port for 1Password to match, not on the address. You did go to 127.0.0.1:port in your address bar first before asking 1Password to fill, right? 1Password switch to a different method when it has no domain name, it matches on the IP address and port.

trailmax

@MikeT OK, that makes sense. Thanks for the explanation. Understanding what is happening behind the scenes does help with issues.
As for accessing systems via ip:port - not an option for me, as the applications I'm working on are using the domain name to identify the tenant. And they all are running on port 80 anyway.

I'll just have to bite the bullet and add all the possible combinations of domain names to 1PW record to get it working. This is indeed a very edge case for you guys.

Let's close this case, I'll re-adjust my 1PW habits to fit in with the new application.

Thanks for your help!

MikeT

Hi @trailmax,

You're welcome! We will fix this for sure in a future update. We actually had it working at some point but ran into more edge cases that we need to address.

gmichels

Sorry for sort of hijacking the thread but I wanted to ask if the same behavior is applicable to .local domains? I have a few websites that are AD integrated (like site1.example.local and site2.example.local) and I'd like to have just example.local in 1P since they are all the same user/pw combination, but I am not able to make 1P match. It does work for another AD domain we use, that doesn't use the .local suffix.

I am using 1PX in Chrome, but I tried with FF with 1P6.8 in Windows, same behavior.

MikeT

Hi @gmichels,

Yes, it's the same issue. .local is not a known top level domain (TLD), it is an internal TLD only. Since 1Password doesn't know it is a TLD, it won't be able to do precise matches. It is something we're planning to fix in the future.

gmichels

Thanks for the clarification. Here comes the obligatory follow-up: any ETA for such feature to be implemented? Or at least is it in some roadmap?

MikeT

Hi @gmichels,

We don't have an ETA on that, we generally do not share estimates on anything as per our policy. This is a bug and it is being tracked in our internal tracker but not everything can be fixed at the same time as some things has to wait for other work to be done first, this specific issue is one of them.

shanesmith

Hello,
Looking for an update on this, if available.

We have approx. 395 domains using a domain similar to one.dev.local / two.dev.local / three.dev.local - have attempted different variations of domain name, direct IP address and port number as mentioned above, but it still does not seem to be possible.

At the moment we've been forced to add them all individually as separate websites, but since the list keeps growing, we are hoping for a solution that allows us to use a single website 'location' entry that supports them all.

MikeT

Hi @shanesmith,

Unfortunately, we do not have anything new to share at this moment. We've added some improved matching but it turns out that it didn't like multiple websites saved for the same item.

Direct IP/port works fine for me. I use it all the time for my internal NAS and router pages, they use ip addresses and port. Here's an example:

However, if you have multiple domains on the same address and port, that won't work well like the case of trailmax.

We have plans to rebuild how matching works completely to support custom URLs but it'll take some time.