[wp-trac] [WordPress Trac] #27086: Make auth-check logins work with 1Password

Mon Feb 10 16:01:33 UTC 2014

#27086: Make auth-check logins work with 1Password
------------------------------------+------------------------------
 Reporter:  nacin                   |       Owner:
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Login and Registration  |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:                          |     Focuses:
------------------------------------+------------------------------
Description changed by nacin:

Old description:

> After some conversation on Twitter, I've been testing 1Password's browser
> extensions against WordPress. It works fine when logging in normally, but
> when you get logged out and need to log in from an iframe, it fails
> pretty hard.
>
> Specifically, 1Password decides to fill *every* text input — even those
> that are hidden, that have content, or that aren't in the same form —
> with the login name. This is despite the web form fields being
> configured, present, and matching up perfectly.
>
> (By hidden I'm referring to type="text" that is visually hidden, not
> type="hidden".)
>
> Basic steps to trigger the issue:
>  * Have a login saved from wp-login.php (making sure that your web form
> details are for "log", "pwd" and optionally "rememberme").
>  * Edit a post.
>  * Hit the 1Password global shortcut, ⌘\. It will fill in every text
> input, including the title, the tags meta box input, the slug meta box
> input, etc. It's a mess.
>
> Steps to reproduce with a real login form:
>  * Have a login saved from wp-login.php, etc.
>  * Edit a post.
>  * Delete your login cookies. Wait three minutes, or speed things up by
> calling `wp.heartbeat.connectNow()` in your console.
>  * An iframe should pop up (assuming you're not cross-domain, at least).
> Log in using ⌘\.
>  * It'll log into the iframe and submit it, which closes it.
>  * Note that the title field and all other text fields.
>
> Steps to reproduce to comedic results:
>  * Have a login saved from wp-login.php, etc.
>  * Visit Settings > General.
>  * Delete your login cookies. Wait three minutes, or speed things up by
> calling `wp.heartbeat.connectNow()` in your console.
>  * An iframe should pop up (assuming you're not cross-domain, at least).
> Log in using ⌘\.
>  * It'll log into the iframe and submit it, which closes it.
>  * Note that every single settings field is filled with your login.
>
> Here's a dead-simple HTML page to try that involves two different forms.
> Doesn't matter where the focus is when ⌘\ is invoked. Doesn't matter if
> it's one form, multiple forms, an iframe, whether the other inputs are
> even wrapped by form.
>
> {{{
>
> <!DOCTYPE html>
> <head>
> <meta charset="utf-8" />
> </head>
> <body>
>
> <form>
> <input type="text" name="log" />
> <input type="password" name="pwd" />
> <input type="submit" />
> </form>
>
> <form>
> <input type="text" name="title" />
> <input type="text" name="foo" />
> <input type="text" name="bar" />
> <input type="text" name="baz" />
> </form>
>
> </body>
> </html>
> }}}
>
> It seems that "If the fields saved in a Login item don’t match the ones
> on the page I try to fill what I can"
> ([https://twitter.com/1Password/status/432687921154371584 source]) is
> inaccurate. It doesn't matter whether the fields match; and "fill what I
> can" actually means "randomly stomp on all fields". This reminds me of
> #24364.
>
> Possible solutions:
>  * Disable all other inputs when the iframe is open, and re-enable them
> when closed. (Need to be careful to not re-enable previously enabled
> fields.)
>  * Convince 1Password to release a fix for this. They happen to be
> WordPress users themselves, so it's not out of the question. There are
> numerous options here, as well — not filling in outside of an iframe is
> probably pretty safe, especially when fields also match 1:1. But one
> question would be how quickly they'd make a fix. I'd tend to think we'd
> be able to release 3.9 first. I filed an unrelated report of a simple,
> annoying, and straightforward bug about two months ago; their last bug
> fix release was about a month ago.

New description:

 After some conversation on Twitter, I've been testing 1Password's browser
 extensions against WordPress. It works fine when logging in normally, but
 when you get logged out and need to log in from an iframe, it fails pretty
 hard.

 Specifically, 1Password decides to fill *every* text input — even those
 that are hidden, that have content, or that aren't in the same form — with
 the login name. This is despite the web form fields being configured,
 present, and matching up perfectly.

 (By hidden I'm referring to type="text" that is visually hidden, not
 type="hidden".)

 Basic steps to trigger the issue:
  * Have a login saved from wp-login.php (making sure that your web form
 details are for "log", "pwd" and optionally "rememberme").
  * Edit a post.
  * Hit the 1Password global shortcut, ⌘\. It will fill in every text
 input, including the title, the tags meta box input, the slug meta box
 input, etc. It's a mess.

 Steps to reproduce with a real login form:
  * Have a login saved from wp-login.php, etc.
  * Edit a post.
  * Delete your login cookies. Wait three minutes, or speed things up by
 calling `wp.heartbeat.connectNow()` in your console.
  * An iframe should pop up (assuming you're not cross-domain, at least).
 Log in using ⌘\.
  * It'll log into the iframe and submit it, which closes it.
  * Note that the title field and all other text fields.

 Steps to reproduce to comedic results:
  * Have a login saved from wp-login.php, etc.
  * Visit Settings > General.
  * Delete your login cookies. Wait three minutes, or speed things up by
 calling `wp.heartbeat.connectNow()` in your console.
  * An iframe should pop up (assuming you're not cross-domain, at least).
 Log in using ⌘\.
  * It'll log into the iframe and submit it, which closes it.
  * Note that every single settings field is filled with your login.

 Here's a dead-simple HTML page to try that involves two different forms.
 Doesn't matter where the focus is when ⌘\ is invoked. Doesn't matter if
 it's one form, multiple forms, an iframe, whether the other inputs are
 even wrapped by form.

 {{{

 <!DOCTYPE html>
 <head>
 <meta charset="utf-8" />
 </head>
 <body>

 <form>
 <input type="text" name="log" />
 <input type="password" name="pwd" />
 <input type="submit" />
 </form>

 <form>
 <input type="text" name="title" />
 <input type="text" name="foo" />
 <input type="text" name="bar" />
 <input type="text" name="baz" />
 </form>

 </body>
 </html>
 }}}

 It seems that "If the fields saved in a Login item don’t match the ones on
 the page I try to fill what I can"
 ([https://twitter.com/1Password/status/432687921154371584 source]) is
 inaccurate. It doesn't matter whether the fields match; and "fill what I
 can" actually means "randomly stomp on all fields". This reminds me of
 #24364.

 Possible solutions:
  * Disable all other inputs when the iframe is open, and re-enable them
 when closed. (Need to be careful to not re-enable previously disabled
 fields.)
  * Convince 1Password to release a fix for this. They happen to be
 WordPress users themselves, so it's not out of the question. There are
 numerous options here, as well — not filling in outside of an iframe is
 probably pretty safe, especially when fields also match 1:1. But one
 question would be how quickly they'd make a fix. I'd tend to think we'd be
 able to release 3.9 first. I filed an unrelated report of a simple,
 annoying, and straightforward bug about two months ago; their last bug fix
 release was about a month ago.

--

--
Ticket URL: <https://core.trac.wordpress.org/ticket/27086#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform