How can i fill in passwords for similar sites without copying and pasting them over
I have an issue where i have similar URL's which i need to fill in my username and password. For example .com or .co.uk if i have my username and password saved in .co.uk url and the website in the password card contains .co.uk it only opens .co.uk and fills the details. If i remove the URL. then it never fills the username and password even when i click on it. Is there a way to do this? where i can fill the same username and password for similar urls which only differ in the suffix at the end?
1Password Version: 6.3.5
Extension Version: 4.6.1
OS Version: OSX Sierra
Sync Type: Not Provided
Referrer: kb:undefined, kb-search:filling forms
Comments
-
Greetings @Achchu,
A Login item can have multiple website fields, allowing you to have a Login item match for different domains. If you edit the Login item you should see a empty website field below the filled out ones, simply keep adding for the various domains you want it to match and it should simply work :smile:
If you run into any trouble please let us know.
0 -
the issue is that i do a lot of testing and i change the suffix at the end all the time. but the first part of the url is always the same www.google.com/123 , www.google.com/456 for example. do i have to enter every time i change the suffix. is there a smart way to do this? @littlebobbytables
0 -
Right now, only the full subdomain is considered. Part of the reason for this is that we have to have a way to store the URL of the field in a way that can be efficiently looked up without decrypting all of your items. Right now, we do this with a hash of the full subdomain (
www.google.com
in your example) and a hash of the root domain (google.com
). These hashes get stored and then we hash the hostname and root domain of the URL of the page you're on and look up matching Logins based on those values. We've considered including more in the full subdomain hash such as port number, but beyond that, there's not much we can do to provide more granular matching without the possibility of a lot of really inconsistent, unexpected, buggy, or outright bizarre behavior.I hope that makes some sense why we handle it the way we do. Let us know if you have any other questions.
--
Jamie Phelps
Code Wrangler @ AgileBits0