1Password helper does not match domains with ".test" extension
I develop local sites using the ".test" domain and save passwords in 1Password 6 for Mac with helper installed on Chrome and Firefox.
Typically, when you open the helper on a site it shows you saved passwords matching the site's domain. So if I'm on google.com or anything else on the google.com domain like support.google.com the helper will show any saved logins matching the google.com domain.
However, when I've saved logins for my .test domains, the helper only matches logins when I'm on example.test but not when on sub.example.test.
Perhaps a bug in 1password or the helper with .test domains?
1Password Version: 6.2.1 (621002) AgileBits Store
Extension Version: 4.5.6.90
OS Version: 10.11.4
Sync Type: Dropbox
Comments
-
Hi @bostondv,
I'll have to ask somebody more informed than myself as we've snuck outside my current comfort zone but I do wonder if it's related to public suffix list. It's just a feeling at the moment but I think whatever is happening it's in 1Password mini which is where my knowledge drops off in terms of specific code.
As it's the weekend I may not be able to locate somebody with the required knowledge but we will get back to you on this.
0 -
@bostondv Sorry it took me a bit to get back to you on this one. @littlebobbytables is right. The public suffix list doesn't include
.testas a known TLD. It does include.dev, so if it's an option, I would recommend using that. The reason for the brokenness is because we calculate two hashes for your URLs, one for the full hostname and one for the root domain name. We locate the root domain name based on that public suffix list. So, for a normal.comdomain, we would see a URL withsub.example.comand calculate the hash forsub.example.comand then use the public suffix list to understand thatexample.comis the root domain.We use this because there are TLDs that have more than one component like
.co.ukor.it.eu.organd making guesses about these proved to just not be good enough and had tons of misidentifications. Essentially, 1Password looks through that list and tries to find the TLD in the URL that is under consideration. In the case of.test, we don't have a TLD in our list for it, so we can't ferret out the root domain to compute the root domain hash for it; all we can compute is the full hostname hash, so when you go tosub.example.testandexample.test, 1Password doesn't see those as containing the same root domain ofexampleat the.testTLD. I hope that makes some sense. It's a pretty complex part of 1Password, and luckily for the vast majority of users, they don't ever have to know anything about this. :) Let us know if you have any other questions.--
Jamie Phelps
Code Wrangler @ AgileBits0 -
Hey Jamie,
Thanks for the explanation, that totally makes sense and is logical that .test wouldn't be in your list since it's explicitly reserved as a an extension that should never be used as a gTLD (https://tools.ietf.org/html/rfc2606#section-2).
However, this is exactly the reason I am using .test in development. Recently since .dev was made available as an ICANN gTLD its started creating name conflicts in the browser when using it as a development site url.
Might it be possible to add the four reserved extensions in RFC2606 (which includes .test) into your TLD extensions to lookup?
I know it's really an edge case but at least for me or anyone else using these reserved extensions for their development sites it'd be very helpful!
0 -
Awesome, thanks!!
0 -
My pleasure!
0
