Refactor OAuth forms; prevent tampering with client ID and secret

Review Request #9056 — Created July 5, 2017 and submitted

Review Board
9053, 9054

The ApplicationForm and UserApplicationForm have been refactored
into the following:

  • ApplicationCreationForm, for creating applications in the admin
    site and through the API;
  • AppplicationChangeForm, for updating applications in the admin site
    and through the API;
  • UserApplicationCreationForm, for users to create applications; and
  • UserApplicationChangeForm, for users to edit applications.

These forms are now more locked down: none of them accept client_id or
client_secret fields. Instead, the *CreationForms will generate
those when creating a new Application. The *ChangeForms will show the
client_id and client_secret fields to users, but any changes made to
them will be ignored.

The above forms now all reject enabling an application that has been
disabled for security reasons (i.e., the original owning user was removed
from the local site the Application is associated with).

The API now is more strict about enabling Applications that have been
disabled for security. Previously, passing enabled=1 into the API
would re-enable a disabled Application and regenerate its client secret.
This behaviour has been updated to explicitly require the
regenerate_client_secret field to be set set truthy. Otherwise an
error will be returned (the same error that is returned when attempting
to enable an Application disabled by security through the above forms).

Ran unit tests.

Loading file attachments...

  • 0
  • 0
  • 1
  • 0
  • 1
Description From Last Updated
  2. reviewboard/oauth/ (Diff revision 1)

    "for security" is a little awkward. Maybe "to keep your server secure"?

Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to release-3.0.x (6d26ef3)