Safari 5.1 not matching logins with no protocol in the URL field

f00f

<div class="IPBDescription">e.g. http:// or https://</div>Greetings,



I've installed Lion GM as well as 1P 3.6.1 and have been banging them around for the past couple of hours. One thing immediately noticed upon installation is that none of my Vault Login items function as they do in Snow Leopard with Safari 5.0; my Login items don't have the scheme (HTTP, HTTPS, etc) listed in the URL field and the Safari 5.1 extension apparently wants complete URLs with the scheme.



To explain further: As convenient as it might be, I never use go-and-fill. I manually navigate to a page and then simply hit Command-\ and hopefully be presented with a listing of all possible Login items for that page. Since I do not rely on go-and-fill -- and for the sake of readability of Login items in the 1P program -- I got in the habit if "cleaning up" the URL fields by removing the scheme bit and the cruft after the first slash after the domain bit. Very often this means the URLs are simply of the form "foo.com". For example, my Google Login items simply have [b]google.com[/b] as their URL; no [i]http:// or https://[/i] or any slashes whatsoever.



This is fine on Snow Leopard with Safari 5.0. In Lion with Safari 5.1 -- not so much. The new extension will complain "No Logins Saved". If, however, I go back and slap the scheme back on the URL fields of the Login items, all is well.



Just an FYI that the scheme appears to be required in Safari 5.1's extension when it wasn't in 5.0.



Thanks,

Keith

khad

Thanks for pointing this out, Keith.



While I would argue that there are some very good reasons that this behavior [i]should[/i] exist in the new extension, but I am not certain that it is by design. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



I will pass this along to the developers! In the mean time, I am pondering the following:



[list=1]



[*]Logins that 1Password saves will always have the protocol. As you mentioned, you had to exert a considerable amount of effort to remove them.

[*]Not specifying the protocol is incorrect in a [i]technical[/i] sense since the protocol is actually a necessary part of the URL.

[*]All modern browsers will automatically add the [i]insecure[/i] [font="Menlo"]http://[/font] if no other (more secure) protocol like [font="Menlo"]https://[/font] is specified, but this is not necessarily the ideal behavior for a security product like 1Password.

[/list]

There was [url="http://forum.agile.ws/index.php?/topic/4435-wish-warn-about-non-secure-signup-login-ie-not-https/"]some discussion about a similar topic in a previous thread[/url] as well (in which I think I espouse some views contradicting the above points, so I think this may not be as designed). <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/laugh.gif' class='bbc_emoticon' alt=':lol:' />



Please let me know if there is anything else I can help with. I'll try to update this thread as I have more information.



Cheers,

f00f

Thanks for the reply, Khad.



To reply to your three points:



[list=1]

[*]I would edit the Login items during the initial saving process. Not too much work to strip out the scheme. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_wink.png' class='bbc_emoticon' alt=';-)' />

[*]Of course!

[*]This is a non-issue when not using go-and-fill, and instead just using 1P as a password database keyed by website domain.

[/list]



A lot of this boils down to personal preference and, perhaps, non-standard usage habits but -- my initial interest in 1P way back when was just as an encrypted password manager that could fill form data (namely, username and password) on demand via a keystroke or whatever. It's not unlike a browser's own password manager in this simplistic sense, except for the glaring facts that 1P works with many browsers, Dropbox, has mobile apps, etc -- all of which *alone* make it very valuable to me as a user. However I always felt go-and-fill to be a [url="http://en.wikipedia.org/wiki/Feature_creep"]feature creep[/url] item and it simply never grew on me. I was very content just having a password database keyed by domain name. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_wink.png' class='bbc_emoticon' alt=';-)' />



All of this makes perfect logical sense to my unconventional neural mass. I view, for example, my Google Login items as such:



"This Login item is my u[b]sername & password[/b] for all things within the [b]google.com[/b] domain" And, considering that Google's sites all (seem) to use the same fields for their username/password fields, this statement is true.



Likewise for my Apple login. I can use it to log in to the Apple Store, the development site, or any place within apple.com (again, because their login fields are the same across different pages). Yes, I realize that if there was a full URL in the Login item I could still use it to log into other pages within the apple.com domain that don't match that full URL (it only has to match the [b]bold part[/b], correct?), but then why is the full URL [i]even there to begin with[/i]?? Purely for go-and-fill? A feature I don't ever use? That full URL is then a mere bit of unnecessary clutter that doesn't logically jive at all with how I use this app.



Again -- personal preference and perhaps non-standard usage habit, but hopefully this sheds a bit more light on the topic. I ultimately just wanted to point out the URL behavior difference between the two extensions. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />



Thanks again,

Keith

khad

The URL that 1Password saves is not only used for Go & Fill — a feature I don't use much myself — but also for matching multiple login credentials to different login pages within the same domain. (cf. [url="http://forum.agile.ws/index.php?/topic/3967-precise-url-matching/"]Precise URL Matching[/url]).



I think the issue here is not so much that the full URL needs to be specified — it doesn't — but that the protocol may be a necessary part of the URL matching. Again, this is just my speculation since I have not heard back from the devs on this particular issue just yet. It is very well just a bug, and I should stop writing so much about it. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



Thanks again for bringing this to our attention. I would have personally never known about it since I haven't gone through and removed the protocol from all the URLs in my data file. This is definitely something we need to either fix or make clear in our documentation!

blake.jordan

Sorry to bring back a somewhat old post - but are there any updates on this? I suppose I think the same way as Keith since I have done the exact same thing - so I have 200 something logins saved with no protocol specified, meaning 1password is significantly impaired for me right now. If its a planned fix, then I'll hold out for it, but if this is the new intended behavior, then I suppose I have to adapt somehow rather than holding out for a fix.



Thanks,

Blake

roustem

[quote name='blake.jordan' timestamp='1311379579' post='33133']

Sorry to bring back a somewhat old post - but are there any updates on this? I suppose I think the same way as Keith since I have done the exact same thing - so I have 200 something logins saved with no protocol specified, meaning 1password is significantly impaired for me right now. If its a planned fix, then I'll hold out for it, but if this is the new intended behavior, then I suppose I have to adapt somehow rather than holding out for a fix.



Thanks,

Blake

[/quote]



Thank you for reminding about this problem. I am working on it now and hope to get it fixed soon.

roustem

This problem is now fixed and will be included in the next 1Password update (3.6.5.BETA-3 or later).



You will need to remove and then install back the Safari extension to force 1Password to update all items in the extension's database.



Thank you again for your help!

blake.jordan

Thanks for the quick reply, and even more for the quick fix! Great support as always.

khad

On behalf of Roustem and all of us here, you are quite welcome! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



If we can be of further assistance, please let us know.



We are always here to help!