Implement APIKey as django form + recaptcha field #22759
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes: mozilla/addons#15083
Description
This PR refactors the
APIKeyPage
view to utilize a django form, both to support using the recaptcha field as part of the flow, and to make the form logic more consolidated and easier to test/grok.Context
Previously, the logic for managing the API key page was kind of murky and spread/duplicated between the view and the template layer.
Now, there is a Django form
APIKeyForm
that is managing the state machine of which actions a developer has available, what is the current state of the relevant entities (confirmation + credentials) and which fields + validations should be in scope.This is a dynamic form that can model the full state of the API key lifecycle from requesting a confirmation, confirming + generating, revoking, and regenerating credentials.
The underlying logic is largely the same as before, but to support the re-captcha a few key changes have been made.
the re-captcha field is now included in the "confirm" stage, when a user does not have a confirmation or credentials.
if a user has credentials but no confirmation, they are shown the credentials view with ONLY the revoke action. Previously we handled creating the confirmation to allow them to regenerate but now, we don't know if they have re-captcha complete and it is simpler to remove that action and force the developer to reenter the flow from the beginning.
We use GET parameters to prefill the confirmation code, but the API is exposed as a post endpoint so it is (unlikely but) possible to submit both a POST and GET token. this is explicitly handled to prefer the POST over the get and covered with a test.
Testing
I'm going to document the entire flow in the issue since there are really a lot of edge cases with this form.
Checklist
#ISSUENUM
at the top of your PR to an existing open issue in the mozilla/addons repository.