Expand the "PhabricatorExternalAccount" table for new registration

Summary:
Ref T1536. This is the schema code for `PhabricatorExternalAccount` which was previously in D4647. I'm splitting it out so I can put it earlier in the sequence and because it's simple and standalone.

Expands `PhabricatorExternalAccount` to have everything we need for the rest of registration.

Test Plan: Implemented the remainder of new registration on top of this.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6169
Remove OAuth token/expiry interfaces

Summary:
Ref T1536. Currently, we store OAuth tokens along with their expiry times and status. However, all we use this for is refreshing profile pictures and showing a silly (and probably somewhat confusing) interface about token status.

I want to move this storage over to `PhabricatorExternalAccount` to make the cutover easier. Drop it for now, including all the profile image stuff (I plan to rebuild that in a more sensible way anyway).

Test Plan: Viewed screen; linked/unlinked accounts.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6170
Internalize storage access for PhabricatorUserOAuthInfo

Summary:
Ref T1536. Move all access to the underlying storage to inside the class. My plan is:

  - Migrate the table to ExternalAccount.
  - Nuke the table.
  - Make this class read from and write to ExternalAccount instead.

We can't get rid of OAuthInfo completely because Facebook still depends on it for now, via registration hooks.

Test Plan: Logged in and registered with OAuth.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6171
Migrate the OAuthInfo table to the ExternalAccount table

Summary: Ref T1536. Migrates the OAuthInfo table to ExternalAccount, and makes `PhabricatorUserOAuthInfo` a wrapper for an ExternalAccount.

Test Plan: Logged in with OAuth, registered with OAuth, linked/unlinked OAuth accounts, checked OAuth status screen, deleted an account with related OAuth.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6172
Conpherence - fix no messages button

Summary: make it work with z-index and make it grey.

Test Plan:
clicked the grey button and it worked! Safari and Chrome

clicked around and observed loading mask functioning correctly

Reviewers: epriestley, chad

Reviewed By: epriestley

CC: aran, Korvin

Maniphest Tasks: T3396

Differential Revision: https://secure.phabricator.com/D6207
Migrate PhabricatorUserLDAPInfo to PhabricatorExternalAccount

Summary: Ref T1536. This is similar to D6172 but much simpler: we don't need to retain external interfaces here and can do a straight migration.

Test Plan: TBA

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6173
New Registration Workflow

Summary:
Currently, registration and authentication are pretty messy. Two concrete problems:

  - The `PhabricatorLDAPRegistrationController` and `PhabricatorOAuthDefaultRegistrationController` controllers are giant copy/pastes of one another. This is really bad.
  - We can't practically implement OpenID because we can't reissue the authentication request.

Additionally, the OAuth registration controller can be replaced wholesale by config, which is a huge API surface area and a giant mess.

Broadly, the problem right now is that registration does too much: we hand it some set of indirect credentials (like OAuth tokens) and expect it to take those the entire way to a registered user. Instead, break registration into smaller steps:

  - User authenticates with remote service.
  - Phabricator pulls information (remote account ID, username, email, real name, profile picture, etc) from the remote service and saves it as `PhabricatorUserCredentials`.
  - Phabricator hands the `PhabricatorUserCredentials` to the registration form, which is agnostic about where they originate from: it can process LDAP credentials, OAuth credentials, plain old email credentials, HTTP basic auth credentials, etc.

This doesn't do anything yet -- there is no way to create credentials objects (and no storage patch), but I wanted to get any initial feedback, especially about the event call for T2394. In particular, I think the implementation would look something like this:

  $profile = $event->getValue('profile')

  $username = $profile->getDefaultUsername();
  $is_employee = is_this_a_facebook_employee($username);
  if (!$is_employee) {
    throw new Exception("You are not employed at Facebook.");
  }

  $fbid = get_fbid_for_facebook_username($username);
  $profile->setDefaultEmail($fbid);

  $profile->setCanEditUsername(false);
  $profile->setCanEditEmail(false);
  $profile->setCanEditRealName(false);
  $profile->setShouldVerifyEmail(true);

Seem reasonable?

Test Plan: N/A yet, probably fatals.

Reviewers: vrana, btrahan, codeblock, chad

Reviewed By: btrahan

CC: aran, asherkin, nh, wez

Maniphest Tasks: T1536, T2394

Differential Revision: https://secure.phabricator.com/D4647
Generalize login flows for new registration

Summary:
Ref T1536. None of this code is reachable.

`PhabricatorAuthLoginController` provides a completely generic login/link flow, similar to how D6155 provides a generic registration flow.

`PhabricatorAuthProvider` wraps a `PhutilAuthAdapter` and glues the generic top-level flow to a concrete authentication provider.

Test Plan: Static only, code isn't meaningfully reachable.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6159
Put some glue in between PhabricatorAuthProvider and the OAuth adapters

Summary: Ref T1536. None of this code is reachable. Glues AuthProvider to OAuthAdapter.

Test Plan: Code is unreachable.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6160
Provide start screen and full registration flow on the new auth stuff

Summary:
Ref T1536. Code is intentionally made unreachable (see PhabricatorAuthProviderOAuthFacebook->isEnabled()).

This adds:

  - A provider-driven "start" screen (this has the list of ways you can login/register).
  - Registration actually works.
  - Facebook OAuth works.

@chad, do you have any design ideas on the start screen? I think we poked at it before, but the big issue was that there were a limitless number of providers. Today, we have:

  - Password
  - LDAP
  - Facebook
  - GitHub
  - Phabricator
  - Disqus
  - Google

We plan to add:

  - Asana
  - An arbitrary number of additional instances of Phabricator

Users want to add:

  - OpenID
  - Custom providers

And I'd like to have these at some point:

  - Stripe
  - WePay
  - Amazon
  - Bitbucket

So basically any UI for this has to accommodate 300 zillion auth options. I don't think we need to solve any UX problems here (realistically, installs enable 1-2 auth options and users don't actually face an overwhelming number of choices) but making the login forms less ugly would be nice. No combination of prebuilt elements seems to look very good for this use case.

Test Plan: Registered a new acount with Facebook.

Reviewers: btrahan, chad

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6161
Implement new auth login flow and login validation controller

Summary:
Ref T1536. None of this code is reachable.

Implements new-auth login (so you can actually login) and login validation (which checks that cookies were set correctly).

Test Plan: Manually enabled FB auth, went through the auth flow to login/logout. Manually hit most of the validation errors.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6162
Add password authentication and registration to new registration

Summary:
Ref T1536. Ref T1930. Code is not reachable.

This provides password authentication and registration on the new provider/adapter framework.

I sort of cheated a little bit and don't really route any password logic through the adapter (instead, this provider uses an empty adapter and just sets the type/domain on it). I think the right way to do this //conceptually// is to treat username/passwords as an external black box which the adapter communicates with. However, this creates a lot of practical implementation and UX problems:

  - There would basically be two steps -- in the first one, you interact with the "password black box", which behaves like an OAuth provider. This produces some ExternalAccount associated with the username/password pair, then we go into normal registration.
  - In normal registration, we'd proceed normally.

This means:

  - The registration flow would be split into two parts, one where you select a username/password (interacting with the black box) and one where you actually register (interacting with the generic flow). This is unusual and probably confusing for users.
  - We would need to do a lot of re-hashing of passwords, since passwords currently depend on the username and user PHID, which won't exist yet during registration or the "black box" phase. This is a big mess I don't want to deal with.
  - We hit a weird condition where two users complete step 1 with the same username but don't complete step 2 yet. The box knows about two different copies of the username, with two different passwords. When we arrive at step 2 the second time we have a lot of bad choices about how to reoslve it, most of which create security problems. The most stragihtforward and "pure" way to resolve the issues is to put password-auth usernames in a separate space, but this would be incredibly confusuing to users (your login name might not be the same as your username, which is bizarre).
  - If we change this, we need to update all the other password-related code, which I don't want to bother with (at least for now).

Instead, let registration know about a "default" registration controller (which is always password, if enabled), and let it require a password. This gives us a much simpler (albeit slightly less pure) implementation:

  - All the fields are on one form.
  - Password adapter is just a shell.
  - Password provider does the heavy lifting.

We might make this more pure at some point, but I'm generally pretty satisfied with this.

This doesn't implement the brute-force CAPTCHA protection, that will be coming soon.

Test Plan: Registered with password only and logged in with a password. Hit various error conditions.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, chad

Maniphest Tasks: T1536, T1930

Differential Revision: https://secure.phabricator.com/D6164
Add Disqus OAuth to new flows

Summary: Ref T1536. Adds Disqus as a Provider.

Test Plan: Registered and logged in with Disqus.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6165
Add GitHub auth to new flows

Summary: Ref T1536. Support for GitHub on new flows.

Test Plan: Registered and logged in with GitHub.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6166
Add Google support to new registration flow

Summary: Ref T1536. Adds Google support.

Test Plan: Registered and logged in with Google.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6167
Move LDAP to new registration flow

Summary:
Ref T1536. LDAP is very likely the worst thing in existence.

This has some rough edges (error handling isn't perfect) but is already better than the current LDAP experience! durrr

Test Plan: Registered and logged in using LDAP.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, mbishopim3

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6177
Replace old login validation controller with new one

Summary: Ref T1536. We can safely replace the old login validation controller with this new one, and reduce code dplication while we're at it.

Test Plan: Logged in with LDAP, logged in with OAuth, logged in with username/password, did a password reset.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6178
Support "state" parameter in OAuth

Summary:
Ref T1445. Ref T1536. Although we have separate CSRF protection and have never been vulnerable to OAuth hijacking, properly implementing the "state" parameter provides a little more certainty.

Before OAuth, we set a random value on the client, and pass its hash as the "state" parameter. Upon return, validate that (a) the user has a nonempty "phcid" cookie and (b) the OAuth endpoint passed back the correct state (the hash of that cookie).

Test Plan: Logged in with all OAuth providers, which all apparently support `state`.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, arice

Maniphest Tasks: T1445, T1536

Differential Revision: https://secure.phabricator.com/D6179
Store the digest of the registration key, not the key itslef

Summary: Ref T1536. Like D6080, we don't need to store the registration key itself. This prevents a theoretical attacker who can read the database but not write to it from hijacking registrations.

Test Plan: Registered a new account.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6188
Liberate after merges.