Refactor OAuth forms; prevent tampering with client ID and secret
Review Request #9056 — Created July 5, 2017 and submitted
UserApplicationFormhave 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_secret fields. Instead, the
*CreationForms will generate
those when creating a new Application. The
*ChangeForms will show the
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.
"for security" is a little awkward. Maybe "to keep your server secure"?