The two factor authentication account string only had the user's
email address. This led to ambiguous entries in two factor
code generating apps. This adds the GitLab host to the account
string in the standard format (according to Google). No matter
the code generator this change disambiguates the entry.
1. Remove an unnecessary (since we're fetching all the records anyway)
`pluck` while fetching U2F registration records.
2. Align "Your device was successfully set up!" section with the "U2F
Devices" table below.
1. Display a list of U2F devices on the `two_factor_auth` page.
2. Allow deleting individual U2F devices.
3. Allow setting a (optional) name for a device (during registration).
1. Only on supported Chrome versions
2. Mainly, this lets us simplify the javascript-based U2F check to
`window.u2f`, where `window.u2f` can either be loaded from the GitLab
server (for Chrome) or from the Firefox extension.
3. This is a better way to provide browser detection for U2F.
- Move the `TwoFactorAuthsController`'s `new` action to `show`, since
the page is not used to create a single "two factor auth" anymore. We
can have a single 2FA authenticator app, along with any number of U2F
devices, in any combination, so the page will be accessed after the
first "two factor auth" is created.
- Add the `u2f` javascript library, which provides an API to the
browser's U2F implementation.
- Add tests for the JS components
Prior, if the user had enabled and then disabled 2FA, they would be
shown a "You must enable Two-factor Authentication for your account."
message when going back to re-activate it, even if 2FA enforcement was
disabled.
Douwe Maan