Add support for custom authentication forms for hosting services.

Review Request #8149 — Created May 6, 2016 and submitted — Latest diff uploaded

Information

Review Board
release-2.0.x

Reviewers

Up until now, we made the assumption that every hosting service just
needed a username and a password (which was sometimes an API key). This
isn't always sufficient, though, and we've worked around this limitation
in the past by taking per-repository fields for additional
credential-related information, which really should have been part of
the account details.

Now, hosting services can define an authentication form. This manages
fields for the hosting URL (if self-hosted), username/password, and
two-factor auth token. Subclasses can override the help text and labels
for these, override the fields completely, or create new fields.

The form is responsible for all validation for authentication
information, the transformation of the fields into a set of credentials
for authorization, and the authorization flow itself. It's also
responsible for state like which of the fields are required or presented
to the user (allowing us to remove some of the hacks in JavaScript).

The main repository configuration form now instantiates one of these
authentication forms for every hosting service. This means that for
every hosting service, the authentication fields are independent,
preventing errors from showing up in an auth form when moving between
hosting services, and preventing other such weird glitches we had with
sharing the auth form.

There's one UI change to how accounts for self-hosted services work.
Previously, the hosting URL field would appear before the accounts
field. You'd type the URL to the service, and the list of accounts
would update to show only those from that service. Now, we show all
accounts across all URLs, each showing the hosting URL its mapped to as
part of the name). The hosting URL is then shown below that (only when
linking an account). This helps make it clear what accounts you have.

The other major change is that re-authenticating now allows you to
change the username and hosting URL, if needed. Previously, this was not
allowed.

All-in-all, this change helps move us to a model where RepositoryForm
doesn't have to do all the work, and we're able to better split up
responsibilities. Similar changes will follow for repository and bug
tracker configuration in the future.

Unit tests pass.

Manually tested the following conditions:

  • Creating a new repository and account with no errors.
  • Creating a new repository and account with auth field errors, and then
    fixing them.
  • Creating a new repository and account with two-factor auth code required,
    and then entering it.
  • Creating a new repository and account with self-hosted service.
  • Creating a new repository with existing account.
  • Creating a new repository with existing account requiring re-auth, and
    providing new credentials (new username, new password, new hosting URL,
    new two-factor auth code).
  • Creating a new repository without a hosting service.
  • Creating a new repository with a hosting service using a custom auth
    form (repeating the above tests).
  • Creating a new repository with bug tracker configurations (both with
    new information and with using the selected hosting service's information).
  • Editing a repository (with all the above tests)
    Loading...