This is a staging forum for AgileBits, not an official support forum. Visit http://discussions.agilebits.com instead.
Safari 5.1 Extension Needs More Lenient URL Matching
One of my current big gripes with the Safari 5.1 extension is that it doesn't show up logins at all for some sites that used to be matched in the past.
After examining further, it appears that the sites in question are ones where the protocol (http:// or https://) has been omitted, which I tend to do when creating logins manually, or sometimes to avoid quirks in the old URL matching scheme.
Anyway, it identifies an issue with the extension's URL matching which seems to be failing if the protocol doesn't match the site.
A better mechanism would be ignore the protocol when attempting a match, focusing on just the domain part itself first like so:
[list][*]Match top-level domain.
[*]Match second level domain.
[*]Match lower level domains (if contained within login entry) - i.e: a login for mydomain.com should match subdomain.mydomain.com, but a login for subdomain.mydomain.com should not match mydomain.com.
[*]Use path segments within login entry to provide relevance (the more pieces matched, the more relevant).[/list]
If a login entry specifies a secure protocol, such as https://, then 1Password should warn that you're trying to use it over an insecure protocol (http://) and allow you the option for marking that entry as protocol locked, such that will only appear for an https:// URL. Likewise, if an entry doesn't specify a protocol, but you are using it for a secure protocol URL then you should get the option of protocol locking it in future.
I think this behaviour should give a good balance of leniency in matching, and protocol security so we can get the best of both. One of the suggestions I posted a while ago was to also have 1Password store last-known certificates for a login, such that it can check these as well and issue a warning if the certificate has changed and the new one can't be verified.
After examining further, it appears that the sites in question are ones where the protocol (http:// or https://) has been omitted, which I tend to do when creating logins manually, or sometimes to avoid quirks in the old URL matching scheme.
Anyway, it identifies an issue with the extension's URL matching which seems to be failing if the protocol doesn't match the site.
A better mechanism would be ignore the protocol when attempting a match, focusing on just the domain part itself first like so:
[list][*]Match top-level domain.
[*]Match second level domain.
[*]Match lower level domains (if contained within login entry) - i.e: a login for mydomain.com should match subdomain.mydomain.com, but a login for subdomain.mydomain.com should not match mydomain.com.
[*]Use path segments within login entry to provide relevance (the more pieces matched, the more relevant).[/list]
If a login entry specifies a secure protocol, such as https://, then 1Password should warn that you're trying to use it over an insecure protocol (http://) and allow you the option for marking that entry as protocol locked, such that will only appear for an https:// URL. Likewise, if an entry doesn't specify a protocol, but you are using it for a secure protocol URL then you should get the option of protocol locking it in future.
I think this behaviour should give a good balance of leniency in matching, and protocol security so we can get the best of both. One of the suggestions I posted a while ago was to also have 1Password store last-known certificates for a login, such that it can check these as well and issue a warning if the certificate has changed and the new one can't be verified.
Flag
0
Comments
-
[quote name='Haravikk' timestamp='1313058523' post='38482']
After examining further, it appears that the sites in question are ones where the protocol (http:// or https://) has been omitted, which I tend to do when creating logins manually, or sometimes to avoid quirks in the old URL matching scheme.
[/quote]
This should be fixed in the latest release. I just tried deleting the "https://" protocol from my GMail account and it was still offered as a choice for filling.
Please make sure you're using the latest versions (currently 3.7.5 for Mac, 3.7 for Safari). If you are already, try completely uninstalling the Safari extension and reinstalling it. This will force the Safari data to be completely recreated and should fix the issue.Flag 0 -
Sorry for the late update, but I still encounter this issue, even after re-installing the Safari extension and clearing every cache that I can think of.
Maybe it only affects entries that already lack a protocol? I have been updating entries as I encounter them, but it's a little annoying when it does happen.Flag 0
