RFE: non-greedy sub-domain matching
For our product we use a base domain name for the production environment (example.com), so each customer has a 'live' domain name of foo.example.com, bar.example.com, etcetera. For simplicities sake, and to make our customers' and developers' lives easier, we use sub-domains of the base domain for dev, staging and uat (dev.example.com, staging.example.com, etc.), so for one customer their domains are:
foo.dev.example.com
foo.staging.example.com
foo.uat.example.com
foo.example.com
Each of those are different environments of the same product. The problem we have is that having per customer entries in 1password is an admin nightmare, so instead we use wildcards (*.example.com, *.dev.example.com). The problem is that a 1password entry of *.example.com is matching *.dev.example.com.
To look at this from an RFC perspective, for wildcard public key certificates, it is impossible to have a certificate provisioned for ..example.com; a wildcard certificate is only valid for a single level of a domain. So, I would expect that 1password behave in a similar way instead of being greedy and matching infinite levels of sub-domain.
Are you aware of this issue? Can you fix it?
I hope this is clearer than mud :)
Ta,
Phil
p.s. this seems similar to the 'lenient url matching' option that was in 1pass v5.
p.p.s. we run a heterogeneous operating environment of Mac and Linux with Chrome and Firefox. The 1passwordX plugin was a game changer for us, thank you).
1Password Version: 7.x
Extension Version: all
OS Version: all
Sync Type: Not Provided
Comments
-
p.p.s. we run a heterogeneous operating environment of Mac and Linux with Chrome and Firefox. The 1passwordX plugin was a game changer for us, thank you).
@cdsphil: I know I'm doing this backward, but I couldn't resist. Thank you for saying so! We really created 1Password X just for you and others in that kind of environment, and it's so wonderful to hear that it's helped you. :chuffed:
p.s. this seems similar to the 'lenient url matching' option that was in 1pass v5.
What you're requesting is in fact the exact opposite of lenient URL matching, which was removed, frankly, because it confused everyone — including us at times. It came up almost exclusively because someone had enabled it not understanding what it did (and I can't blame them; it's difficult even for us to describe, hence the awkward wording). Invariably, the solution was to disable it again. So we took it to the next step and just got rid of the option altogether. Now the 1Password desktop apps prioritize subdomain.domain.tld matches and display domain.tld matches below as "related". What you're looking for would be more like "super strict matching". Clear as mud indeed. :lol:
Each of those are different environments of the same product. The problem we have is that having per customer entries in 1password is an admin nightmare, so instead we use wildcards (*.example.com, *.dev.example.com). The problem is that a 1password entry of *.example.com is matching *.dev.example.com.
It's worth noting that "wildcards" do absolutely nothing in 1Password. It's better to just save the actual URL for the page, since that will allow 1Password to take you there.
Are you aware of this issue? Can you fix it?
This is working as designed. I get where you're coming from, and certainly this comes up from time to time, but we have to keep in mind that making this change would confuse many more people than just those of us who confuse ourselves trying to talk about this sort of thing. The majority of 1Password users are not in an environment where they have X number of separate accounts for different subdomains, etc. of the same domain. Obviously it would be more convenient for us to have only discussions.agilebits.com logins displayed at this forum, etc., as opposed to all of our agilebits.com logins, but that small convenience for us (and you) would come at a great cost to others — all so you and I had one less click or keystroke to fill. There's got to be a high bar for changing things that work for most use cases. The pros really need to outweigh the cons for the 1Password userbase as a whole. So it isn't something we have plans for currently, but we'll continue to evaluate as we develop future versions. Thank you for your feedback on this! :)
0 -
Aaaaand it looks like the update to 1passwordX you released today actually 'fixes' the problem we were facing. In the auto-fill for each of our subdomains we are now seeing what we need :). Five stars, would buy again ;)
0 -
Hahaha thank you! I'm really glad to hear that the latest update has solidified your investment. ;) That was a pretty big update, but there's even more to come. Cheers! :chuffed:
0 -
Just curious: is your site listed on Public Suffix List? 1Password treats those top-level domains differently than others.
++dave;
0 -
@dteare, being an Australian entity we use '.com.au'. I like that IANA reserved example.{com,org,net} for.. examples.. We use .local for anything that's purely internal, as it's not internet routeable, but are still able to use 1pass. Do you have doc on how you handle non-public-suffix-matching domains, like '.local'?
@Mitch, yeah, I read the release notes which spurned me to test, JustWorks™ :)
0 -
That's a good question. I believe we simply treat
.localas any other TLD. I wanted to run some tests before replying but my environment isn't setup for that at the moment.Pinging @beyer so he can respond with some explicit examples. Please give him some time, however, as he's travelling at the moment.
++dave;
0
