Refactor OAuth forms; prevent tampering with client ID and secret
Review Request #9056 — Created July 5, 2017 and submitted
The
ApplicationForm
andUserApplicationForm
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; andUserApplicationChangeForm
, for users to edit applications.
These forms are now more locked down: none of them accept client_id
or
client_secret
fields. Instead, the *CreationForm
s will generate
those when creating a new Application. The *ChangeForm
s 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.
Description | From | Last Updated |
---|---|---|
"for security" is a little awkward. Maybe "to keep your server secure"? |
|