Hey, I have another usecase that 1password could help with:
In addition to *..com URLs, we also have internal DNS entries using proprietary top-level domains, e.g.
1Password seems to handle the *..com URLs, but does not fill in on *..EXM URLs. The login form is the same on either URL, it is just a separate DNS entry. You may ask what not just use the .com URL, well we do not force HTTPS on the .EXM URLs which is helpful for internal testing.
@mreynolds0404: Interesting. While wildcards for domains has generated some interest, I think you request for TLD wildcard support is a new one — at least to me! I've added your vote, and while I can't make any promises, we can certainly consider adding something like this in a future version. Thanks for the suggestion!
I notice the domain matching works in the windows version of 1Password :-/
It even has options for domain matching in the preferences: https://guides.agilebits.com/1password-windows/4/en/topic/logins-tab
will the mac version get this feature at some point?
@njs50: That's correct! Manual domain matching settings are one of a few features that 1Password for Windows alone has. We may add that feature to 1Password for Mac in the future. Thanks for letting us know you'd like to see it there as well!
ah, actually it's not the manual domain matching that makes it work. it's just that the windows version isn't broken i.e can match with a different subdomain.
interestingly enough the windows version runs on my mac via wine, bit sad that works better than the mac version, and that version 3 is still the best :-/
We appreciate your feedback about this, @njs50. Thanks again!
I'd really like to see wildcard domain matching work on the Mac, too. One further refinement I'd like to see is that more specific "website" entries should take precedence. For example, given:
Login item 1: example.com default
Login item 2: staging overridehttps://staging.example.com
Login #1 would match e.g. example.com, production.example.com, foo.bar.example.com
But login #2 would match e.g. staging.example.com, baz.staging.example.com
@SethMilliken: That certainly seems reasonable. Thanks for the example(.com ) Hopefully we can add that feature to 1Password in the future!
Very sad to see a fix for this bug, introduced in version 4, didn't make it into version 6 It is still preventing many of us from upgrading from version 3.
@redcoat: Sorry for the confusion! This isn't a bug; rather, 1Password for Mac simply doesn't have this feature currently. That said, domain matching is certainly something we're looking to overhaul to make it more consistent across all platforms. I'm sorry that we didn't meet your expectation of a fix in 6.0, but let's just say that this is something we're looking at now that this major release is out the door.
I'm also disappointed this bug still isn't fixed. Oh well, i guess we've saved on having to upgrade our v3 licences, so that is something.
Sorry to argue what may appear to be semantics, but this isn't a bug that needs fixing. It is a feature request. One that we're considering, but haven't made any promises at this point to do.
As Brenty mentioned cross platform consistency is definitely a long term goal of ours, so there is a good chance we may see this in the future.
Well, you can call it a feature request if it makes you feel better. Something that worked previously and also works across other operating systems doesn't really sound like a new feature to me tho.
In the meantime i'll continue to advocate not upgrading from version 3.
Version 3 is no longer being updated, so we would not recommend running it on newer operating systems, but the choice is yours of course.
I mentioned it was a bug due to the bug report that was filed on your side apparently: https://discussions.agilebits.com/discussion/18745/wildcard-support-in-1password-4-for-mac
"AgileBits Team Member
I'm truely sorry I don't have a solution of even a viable workaround to offer you for this lack of wildcard (sub)domain matching issue with 1P4. I have filed a detailed bug report about it and do appreciate the help and clarification you've provided."
Thanks for the additional insight, @redcoat.
it's also mentioned as a bug on the first page of this thread:
"Now, there is a bug that our developers are currently looking into which might cause Lenient URL matching to not work as expected. So if it doesn't seem to be working as I described above, that is probably due to the bug, and I apologize for the inconvenience! I don't have a timeframe for when that will be fixed, unfortunately."
So it's possible there is also another bug report about the same thing (also from V4).
Being able to press cmd-\ and have a password filled in is a pretty compelling reason to stay with the version where it still works.
@njs50: Domain matching is a complex issue, and any change we make there will result in it working differently than some people expect. In your case, you want it to work the way it used to in 1Password 3, but folks who've been using versions of 1Password released since then expect it to work very differently. We have a number of options to consider, and we'd absolutely prefer to take our time and find a solution that works for most people, rather than simply some. Whether this will mean more granular controls or a more elegant logic behind the scenes remains to be seen.
As I said earlier, its something we're looking into. I won't say more than that since I don't want to overpromise and get your hopes up. But as you also mentioned, you've got 1Password 3 and prefer how that works, and that saves you some money in the mean time anyway. This is an instance where it's clearly on us is to improve it to the point where it you'd see a value in upgrading. If I didn't see a benefit to a new version, I wouldn't pay for it either.
In the docs "lenient url matching" is described as:
"Visiting mail.google.com or accounts.google.com or any subdomain on google.com will match all of your google.com Logins"
It would seem unexpected that there are not any possible match for x.y.z.amazonaws.com with lenient url matching enabled. As described i would expect it to match either anything.amazonaws.com or anything.y.z.amazonaws.com.
Might be worth adding a note to the docs as it's somewhat confusing to anyone trying to use it.
Understood. And we've got some ideas for this. Thanks again for the feedback!
Thanks for letting us know you're also interested in this!
Really need this feature
Thanks for taking the time to tell us!
I'd love to have this feature. Currently managing development environments is a real pain. I'm looking to be able to get https://[environment]-subdomain.pantheon.io working without having to manually enter domains for each.
I've tried the following without success:
I'm running Version 6.5.2 (652003)
@dalin: I'm not sure which "rules" you're referring to, but to be clear, 1Password does not support wildcard hostname matching. It's a feature some folks have requested, so perhaps it will make it into a future version of 1Password. Thanks for letting us know you'd appreciate that as well!
One thing that might help in the mean time if you're using a number of similarly-named URLs would be creating an item as a template which you can duplicate. Then all you need to do is add a subdomain when making a new item. Just a thought. Cheers!
I would also like the ability to use wildcard's in the website name. Just adding my +1!
I think part of the problem is that "Allow filling on pages that closely match saved websites" only works with some TLDs. It's working for .com but not .io .
@mire3212: Thanks for letting us know that you'd like 1Password to support wildcards too!
@dalin: That's an excellent point! While it isn't exactly the same thing as the subject of this discussion, you're right to point it out as it is very much related. A lot has changed in this space, and we're exploring ways to make 1Password better support domain matching. Thanks for bringing this up!
Another +1 for subdomain wildcard matching on the Mac. First of the New Year!