When will browser makers add support to their APIs to allow extensions to access HTTP Basic Auth pro
Comments
-
Warning No formatter is installed for the format ipb0
-
Warning No formatter is installed for the format ipb0
-
Warning No formatter is installed for the format ipb0
-
Warning No formatter is installed for the format ipb0
-
Warning No formatter is installed for the format ipb0
-
Warning No formatter is installed for the format ipb0
-
Warning No formatter is installed for the format ipb0
-
Warning No formatter is installed for the format ipb0
-
khad: I'm sorry for taking so long to respond. I never received notification that anyone had bothered to reply to this thread.
I'm guessing that you aren't a developer. No, not guessing; I'm sure of it. I'm also pretty sure you didn't consult a developer before writing your response.
When you feed a URL in the form of http(s)://USER:PASS@www.blah.com/uri/ to a browser, the browser extracts the relevant information and constructs the proper basic-auth request. At no time is the login information sent 'in the clear'. Well, at least not any more or less in the clear than basic-auth already is. Standard basic auth can be de-hashed on the fly by dsniff, but that is a limitation of the protocol and not because the URL form I gave is somehow less secure.
While it is true that the password wold be communicated 'in the clear' between 1Password and the browser, this is already the case when a password is inseeted into a form field by 1Password. And if you can't trust interprocess communication on your own system, you have problems that 1Password isn't going to fix.
Spend some time with Firefox and Wireshark. After a little testing you'll want to go back and delete your above post.
If I seem particularly bitchy in this post, it is because I've just been told by support: "Support for Basic Authentication logins is on its way, however we don't have an expected time of arrival just yet. Don't worry, it's certainly on the radar. :)" and after two years of hearing the same crap I'm pretty tired of it.
0 -
While your suggestion that http://USER:PASS@url.com/ will work, it is not reliable across all 4 browsers in default browser settings.
Doing this in Safari presents the user with a phishing attempt because the URL contains a username and password.
Doing this in Chrome, Firefox and Opera works.
So, while your solution works in 3/4 of the browsers, leaving out Safari is a pretty big deal.
This is also not entirely a solution because we cannot interact with the form itself. This means if the user brings this page up, the only way for us to fill on it would be by having the user cancel the login and then click the URL directly in 1Password. Not everyone's work flow works this way. So, now we have no consistent reliability in all 4 browsers, but now we have a subpar user experience and an exact flow that has to happen for it to work.
We are also unable to auto-save these logins, they would have to be manually added in the 1Password application, and we'd have to provide an option that it's a HTTP Auth login item. The user would have to select this and this isn't all that user friendly.
While I'd agree, it does work, this isn't the type of experience we really want our users to have to deal with. Currently users can open and use login items in a variety of ways:
- Click the URL in the Login item in the Main application
- Click the Mini app and choose their login item
- Bookmarklet by dragging the login to their browser bookmarks bar
- Going to the site manually (or by non-1Password bookmarklet) and pressing Command+\ to autofill on the page
So, in your case the user would be unable to make this work in case 3, and case 4.
The devil is in the details, and consistency matters.
This is still on our radar, but as with before, we can't promise we can support this nor can we provide a timeframe for when, should we find a way to support it.
Sorry I can't provide any more details than that.
0
