Matching sub-domains [No plans for this]

craig_francis

In 1Password 7 for Mac (beta), it looks like it's started doing a rough top-level domain match for logins.

This might help websites that use a single login for multiple sub-domains, e.g.

https://www.example.com
https://app.example.com

But stops quick selection of logins when there are multiple different systems, e.g.

https://email.example.com

Or in my case, as a developer working on multiple websites, e.g.

https://website1.dev.example.com
https://website2.dev.example.com
https://website3.dev.example.com

For reference, I have 42 logins under my development domain, some use a single login (so would be nice to simply do cmd+/ and enter to login), and some have a few logins (e.g. admin and user accounts).

---

1Password Version: 1Password 7 Version 7.0.BETA-9 (70000009) AgileBit
Extension Version: 4.7.0.90 on Chrome / 7.0.BETA-9 on Safari
OS Version: 10.13.4 (17E199)
Sync Type: DropBox

Lars

@craig_francis - this is an ongoing issue that it's difficult to solve in a way that benefits the small number of people like you who have twenty or thirty logins all for the same domain (different subdomains) while not either breaking things for or increasing complexity for the much larger contingent of users who have only one or at most a couple of logins for any given site. We're always looking into ways we can meaningfully improve the experience for our power-users who have edge cases while not degrading the experience for regular users, but so far a solution that works well for both groups in the case has proven elusive. Thanks for reporting, however!

craig_francis

Thanks for the response Lars,

Would it be possible to do a search for logins on the current (full) domain, and if one or more are found, use that (i.e. the old behaviour)... and if that fails, do a second search based on the top level domain?

I suppose I'm lacking examples of websites that use multiple sub-domains, where those sub-domains aren't completely different systems (i.e. share logins)... I can only think of slack.com, which would work with this fallback search approach.

Ben

That may be a possibility, but it would also potentially be inadvertantly limiting to folks with other scenarios. Something we’ll have to weigh.

One example is production environments that are copied to test environments, but then the test environments are built out. So for example I might have hostnames:

• agilebits.com
• test.agilebits.com

test.agilebits.com is a copy of agilebits.com, so credentials for agilebits.com will work there. But perhaps I then have higher level credentialing for the test environment that only works there, so I also have a login saved for test.agilebits.com with those higher level credentials. With your proposal I’d lose the ability to fill my agilebits.com credentials on test.agilebits.com

Ben

craig_francis

Thanks Ben,

Personally I think that's more of a developer scenario... where developers are more likely to know that the login details stored within 1Password can be used with two or more website addresses (aka domain names)... something that's confirmed when you edit a login, and 1Password shows a blank "website 2" field.

This is how I get this to work with my two accounts on Slack.com (work/home), that span five different projects/sub-domains (one project I use both accounts, 4 are just work based, and 1 is just home based).

Whereas for my development setup, there is nothing I can do... I just have to look though a long list of accounts every time I want to login.

And as an aside, and probably not an issue in your case (because the nature of your business), I would hope that Live data isn't being used in test/development environments, because those systems are rarely secured as well, and you don't want events happening based on that Live data (e.g. emails being sent to real customers)... it's why we have things to populate our databases with thousands of dummy/fake records :-)

Ben

I understand your position. My point is simply that other positions exist, and we need to consider those as well. :) Thanks for the feedback.

Ben

craig_francis

I'd be happy to discuss those positions here... I'm a programmer who has quite a good record of looking at problems from multiple positions.

At the moment I can only see how this change might help in two situations (of which those situations have other solutions), whereas it has simply broken 1Password for the situation I've described.

littlebobbytables

Hi @craig_francis,

I've I've followed correctly then don't worry, it is a bug and it will be fixed. You're used to exact FQDN (Fully Qualified Domain Name) matches always appearing before matches to only the registered domain and the current beta is instead ordering all matches alphabetically by title without any considered as to if it's an exact match to the FQDN. The correct behaviour, what you were used to, will return.

If I've misunderstood please do correct me.

craig_francis

Thanks @littlebobbytables,

You're correct, I'd like the previous (pre bug) behaviour, where logins matching the FQDN appear first.

The logins are currently appearing in alphabetical order, and I'm glad to hear you're aware of the issue, and will be fixing it :-)

Ben

Gotcha! Thanks for the update @craig_francis. We do plan to fix that. We are looking at ways we can continue to improve in this area in general as well.

Thanks.

Ben

craig_francis

Thanks Ben.

Ben

:+1:

Ben

steve28

This is driving me bananas! I like others here, have several instances where I have several different sites with different subdomains off of a main domain and the current behavior of showing me a list really is annoying.

And FWIW, I do think you may be holding back on an oft-requested behavior (just fill the exact match over close matches) for reasons that appear to be 'normal' to you, but only because you live, eat, and breath development where you frequently have to log in to variations of the same domain with different credentials. For most "mere mortals" out here, this is not the behavior desired.

At the very least, could you make a preference: "Preferentially fill in exact domain match"? And if you really want to get fancy, a modifier key to reverse the whatever is currently selected.

AGAlumB

This is driving me bananas! I like others here, have several instances where I have several different sites with different subdomains off of a main domain and the current behavior of showing me a list really is annoying.

@steve28: I'm sorry to hear that. I've got a number myself, but I find it helpful to use search to narrow things down (along with recognizable names).

And FWIW, I do think you may be holding back on an oft-requested behavior (just fill the exact match over close matches) for reasons that appear to be 'normal' to you, but only because you live, eat, and breath development where you frequently have to log in to variations of the same domain with different credentials. For most "mere mortals" out here, this is not the behavior desired.

I think the thing you're overlooking is that it's because we live in this world that a change like this would be more beneficial to us than most people. Frankly we get more support requests because people expect to see a login offered somewhere and it isn't. While I appreciate that for your use case (and, frankly, ours — we have a ton of something.agilebits.com and something.1password.com logins!) it could be helpful to show less, it's more difficult for most users to find "missing" logins than it is to just select the one they want when presented with a list.

At the very least, could you make a preference: "Preferentially fill in exact domain match"? And if you really want to get fancy, a modifier key to reverse the whatever is currently selected.

How about if you have multiple exact subdomain.domain.tld matches? Then we're back to square one. It's something we'll continue to evaluate, but there's nothing stopping you and me from hiding logins we don't want to use, organizing (vaults, tags, Favorites), or narrowing down the results; and that doesn't cause any added confusion or hassle for anyone else.

tvachon

I have logins on many many subdomains for a given domain. I always get 20+ matches on the page, is there a way in 7 (or at all) to disable fuzzy matching for a given domain?

---

1Password Version: 7.0-BETA10
Extension Version: 4.7.1.4
OS Version: OSX 10.13.4
Sync Type: Teams

rodd_zurcher

Same request.

On a site with many subdomains, the current subdomain (e.g. foo.example.com) is mixed with all the other example.com results I'm fine with the whole list being there; but the most closely matched subdomain should be sorted to the top. I even like the version 6 showed top three with a more "link" (with the most closely matched being in the top 3).

Ben

Hi folks. I’ve merged a couple of threads here. Please see above. :)

Ben

craig_francis

Thanks Ben... @tvachon, @rodd_zurcher, I believe this is a bug that will be fixed soon (so it should go back to the old 1Password behaviour, as per the comment by @littlebobbytables).

---

But just to confuse matters even more :-)

The old behaviour (pre bug) was pretty much perfect for me, where it would show the exact matches first, then provide a greyed out "Show X more items" to view the non-exact matches.

I don't think it has ever done this on iOS, which I don't use as often; but when I do, 42 items is quite a long list to search though.

Should I raise this as a separate issue in the iOS forum? I think this might be related to:

https://discussions.agilebits.com/discussion/comment/415706

craig_francis

Ohh, might be worth checking this forums CSS...

.Message hr:last-of-type + p {
    font-size: 12px;
}

I suspect you used to have a <hr /> after the users comment, where it used a smaller font size :-)

Ben

I suspect you used to have a <hr /> after the users comment, where it used a smaller font size :-)

We still do. :) The fact that it inadvertently applies to other hr elements is a bit annoying.

Should I raise this as a separate issue in the iOS forum?

Not necessary. Your feedback is noted. :)

Ben

craig_francis

Thanks Ben,

And as to the CSS, I didn't notice that it's being used for the first message in the thread (to show the version numbers)... but because that first message is kept separate within:

<div class="MessageList Discussion">

You could add .MessageList.Discussion to the CSS rule:

.MessageList.Discussion .Message hr:last-of-type + p {
    font-size: 12px;
}

Where you need both classes, because MessageList is used on both that first comment, and to wrap the other comments... and Discussion is applied to the , and a sub-div (which implies it might appear in other locations).

tvachon

I saw this same behavior in the 6.x train too, not as bad but it was always more liberal than it should have been with matching

Ben

Thanks for the suggestion @craig_francis. I’ll file an issue for that.

Ben

Ben

@tvachon,

There is currently a bug that makes this behave differently than intended. Thanks for the feedback.

Ben

TekGen

URL matching seems to have gotten less specific (or strict as the configuration option used to call it) than v6.8 or older.

I used 1Password for personal and work. At work we have a situation, depending on the application, I could be logging into any number of systems under the same domain name that does not have any federated credentials (like SSO, LDAP, etc). And for the sake of security, my accounts on these systems are complex and unique. So app1.domain.tld and app2.domain.tld could have two different credentials. This is fine when you are talking about quantities of up to 5... but when you have a large quantity... it gets a bit tedious to have to "show more" every time because the one you want is at the bottom.

In most cases, for me at least, matching on specifichost.domain.tld, anyhost.subdomain.domain.tld, and/or specifichost.subdomain.domain.tld would work for me. Just needs to match on more than just domain.tld... and more on the whole FQDN.

The matching URI/path after the domain usually doesn't create issues for me as most things, for me at least, are not differentiated by path but by FQDN.

Maybe even making an option to tune how many levels in the FQDN to match on (ie all but the lowest level [aka hostname], or one subdomain, etc.

---

1Password Version: 7.0.BETA-12 (70000012)
Extension Version: Beta 4.7.1.4 (Firefox)
OS Version: MacOS 10.13.4
Sync Type: 1Password Family

Stephen_C

There is quite a long thread here on a related subject, which includes a comment from AgileBits about an existing bug in the 1Password 7 betas which needs to be squashed.

Stephen

Ben

Merged. Please see above. Thank you!

Ben

yippy3000

+1 on this. The change has been very challenging for me as I have hundreds of logins all on the same top level domain (yay Salesforce consulting)

Ben

Thanks, @yippy3000, this should be fixed before 7.0.

Ben

Unknown

This content has been removed.

Ben

No ETA, sorry. We don’t generally do ETAs.

Ben