forked from django-oauth/django-oauth-toolkit
-
Notifications
You must be signed in to change notification settings - Fork 0
Use class based views to make them more easily extensible #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft
cristiprg
wants to merge
34
commits into
add-device-flow
Choose a base branch
from
add-device-flow-wip-2
base: add-device-flow
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This model represents the device session for the request and response stage See section 3.1(https://datatracker.ietf.org/doc/html/rfc8628#section-3.1) and 3.2(https://datatracker.ietf.org/doc/html/rfc8628#section-3.2)
Django represents headers according to the common gateway interface(CGI) standard. This means it's in all caps with words divided with a hyphen However a lot of libraries follow the pattern of Something-Something so this ensures the header is set correctly so libraries like oauthlib can read it
This method calls the server's create_device_authorization_response method (https://datatracker.ietf.org/doc/html/rfc8628#section-3.2) and is returns to the caller the information adhering to the rfc
The device flow is initiated by sending the client_id and and a scope. This check should not fail if the client is public
OAUTH_DEVICE_VERIFICATION_URI = the uri that comes back from the response so the user knows where to go to. e.g example.com/device OAUTH_DEVICE_USER_CODE_GENERATOR = Allows a custom callable to be passed in to control how the user code is generated, stored in the db and returned back to the caller DEVICE_MODEL = the device model DEVICE_FLOW_INTERVAL = The time in seconds to wait before the device should poll again
This view is to be used in an authorization server in order to provide a /device endpoint
This commit will not be merged(I think). Currently oauthlib is due a release so I'm pointing this to master
A public device code grant doesn't have a client_secret to check
It needs handled differently depending on the device grant type or not it also needs to be rate limited to adhrere to the polling section in the spec so a device can't spam the token endpoint
This creates a user friendly but still high entropy user code to be used in the device flow
Tests the device flow end to end
Older version doesn't work with newer version of python
In this commit I've addressed a few issues raised in comments about the flow. * Always return informative errors to user-facing views. If the device is not in the expected state, the errors are returned in the form, instead of raising exceptions. * Always return JSON response to device-facing view (aka TokenView). If the device is not in the expected state, the errors are returned according to the RFC. * Never involve device_code in frontend. The redirect to device-confirm view now takes client_id and user_code arguments instead of device_code * Increased test coverage. Added tests for expected error cases handled in the code
Perferred to use the Grant suffix in order to keep the naming consistent with other grant models.
This commit updates the views related to device auth flow from functions to class-based views. This makes it easy to import them in other projects and only overwrite small bits of functionality (specifically looking at templates and context_data). A 3rd view is added for the final step where the user is presented with the status of the device after they approve or deny. The views now also have a more "standard" django form behaviour, changes being relfected in the tests.
dd180ec to
733f7a1
Compare
9a37e4f to
824c834
Compare
ac159b0 to
74ffed5
Compare
66b02e3 to
c10a471
Compare
6dc5041 to
47a35bd
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This commit updates the views related to device auth flow from
functions to class-based views. This makes it easy to import
them in other projects and only overwrite small bits of functionality
(specifically looking at templates and context_data).
A 3rd view is added for the final step where the user is presented
with the status of the device after they approve or deny.
The views now also have a more "standard" django form behaviour, changes
being relfected in the tests.
Fixes #
Description of the Change
Checklist
CHANGELOG.mdupdated (only for user relevant changes)AUTHORS