WIP: fix: allow JWT auth for views used in Authoring MFE - #37093
WIP: fix: allow JWT auth for views used in Authoring MFE#37093samuelallan72 wants to merge 1 commit into
Conversation
This is only a proof of concept, work still in progress. Fixes: openedx/frontend-app-authoring#1080 Private-ref: https://tasks.opencraft.com/browse/BB-9549
openedx-webhooks
added
the
open-source-contribution
|
Thanks for the pull request, @samuelallan72! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. 🔘 Update the status of your PRYour PR is currently marked as a draft. After completing the steps above, update its status by clicking "Ready for Review", or removing "WIP" from the title, as appropriate. Where can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources: When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
| @login_required | ||
| # @require_http_methods(("DELETE", "GET", "PUT", "POST", "PATCH")) | ||
| @view_auth_classes() | ||
| @expect_json |
There was a problem hiding this comment.
I feel like we can drop the expect_json decorator here, as django_rest_framework should handle json gracefully. Not sure if we can/should force json-only - I think django_rest_framework will also accept and parse form encoded data too.
| # @require_http_methods(("DELETE", "GET", "PUT", "POST", "PATCH")) | ||
| @view_auth_classes() | ||
| @expect_json | ||
| @api_view(http_method_names=["DELETE", "GET", "PUT", "POST", "PATCH"]) |
There was a problem hiding this comment.
I'm not sure yet if the api_view decorator makes any changes that would subtly break any assumptions of normal django request handlers (eg. with error handling). Also not sure if we should use the function based decorator here, or go for a class based API view - similar to https://github.com/samuelallan72/edx-platform/blob/efc77256a832e464f6aba3e3a7bef9de1702a539/openedx/core/djangoapps/content_libraries/rest_api/blocks.py#L430-L440 (this code was written in #35765 as part of an API conversion to fix a similar issue)
| @transaction.non_atomic_requests | ||
| @require_http_methods(("DELETE", "GET", "PUT", "POST", "PATCH")) | ||
| @login_required | ||
| # @require_http_methods(("DELETE", "GET", "PUT", "POST", "PATCH")) | ||
| @view_auth_classes() | ||
| @expect_json |
There was a problem hiding this comment.
For the existing decorators, I'm not sure yet if they are fully compatible with the DRF api_view, or if any particular order is required. For example, I discovered that here expect_json must be before api_view, otherwise the request crashes with an error about reading the request body more than once.
|
Hi @samuelallan72! Is this pull request still in progress? |
|
@mphilbrick211 yes it is - we're just temporarily blocked internally right now. This is definitely still something we want though, and will likely resume development within the next month or so. Thanks. :) |
mphilbrick211
added
the
blocked by other work
|
@samuelallan72 thank you for this! This issue came up again during the ulmo release testing cycle: openedx/wg-build-test-release#560, so it's something we all want to push forward. Let us know how we can help. |
|
Thanks @mariajgrimaldi , let me check internally to see where this is at. :) |
|
Hi @mariajgrimaldi unfortunately we don't have budget to continue at this stage sorry. If this is more widely wanted now, would you or another community member be interested in taking this over? I'd be very happy to support with any more context if needed. :) |
|
@samuelallan72: thank you so much for all the work! I'll try to find someone to work on it |
|
Thanks @mariajgrimaldi :) |
mphilbrick211
removed
the
blocked by other work
|
Hi @samuelallan72 @mariajgrimaldi! Is this still in progress? |
|
@mphilbrick211 I don't know of any status updates since @mariajgrimaldi's comment above. From our end, we're still in the same situation of not being able to continue on this. |
|
Hey @mariajgrimaldi, are you still planning to pick this up? |
farhaanbukhsh
left a comment
farhaanbukhsh
left a comment
There was a problem hiding this comment.
@mariajgrimaldi I'm closing this PR. I will not delete the branch in case someone wants to cherry-pick it. cc: @itsjeyd @mphilbrick211 @samuelallan72
github-project-automation
Bot
moved this from Ready for Review
to Done
in Contributions
6 participants
Description
Avoid authentication errors from MFEs (specifically the Authoring MFE here) in the case where the LMS is logged in, but Studio is not yet authenticated.
Fixes: #1080
TODO:
Supporting information
Private-ref: https://tasks.opencraft.com/browse/BB-9549
Testing instructions
Other information
See also openedx/frontend-app-authoring#1080 (comment) and openedx/frontend-app-authoring#2335 . There may be alternate or better methods of implementing this.