fix: CSRF errors in POST requests to LMS #33790
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.
This is a Quince backport of #33727 cc @mariajgrimaldi
POST requests to the LMS are failing systematically when HTTPS is enabled. This issue is observed in the Quince release branch. Here is the root cause analysis:
is_secure
attribute by setting it to "false".process_view
method, from the CsrfViewMiddleware.We resolve this issue by running the CsrfViewMiddleware before the custom CorsCSRFMiddleware. After a successful check of the CsrfViewMiddleware, the request has the "csrf_processing_done = True" attribute, and CorsCSRFMiddleware is short-circuited.
This issue did not happen in the following environments:
To bypass this issue in the master branch, it was proposed that we add "https://LMSHOST" to CSRF_TRUSTED_ORIGINS. This would effectily bypass CSRF checking entirely for all requests that originate from the LMS. Such a solution would not be acceptable, as we would lose the security guarantees offered by CSRF.
See discussion: openedx/wg-build-test-release#325