feat: integrated resumeCourseRunUrl into enrollments API
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
Upgrade edx-drf-extensions 9.0.0
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
edx-drf-extensions 9.0.0 requires VERIFY_LMS_USER_ID_PROPERTY_NAME
to be properly set in LMS to get the appropriate verification when
forgiving JWTs is enabled (which will soon be by default).
See openedx/edx-drf-extensions#408 for details.
This is part of:
edx/edx-arch-experiments#429
Co-authored-by: robrap <robrap@users.noreply.github.com>
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:
- CorsCSRFMiddleware overrides the `is_secure` attribute by setting it
to "false".
- CorsCSRFMiddleware calls the parent `process_view` method, from the
CsrfViewMiddleware.
- CsrfViewMiddleware checks the Origin header, including the scheme. It
is equal to "https://LMSHOST". But because the request is not
considered secure, the expected origin is "http://LMSHOST".
- The check fails with "Origin checking failed"
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:
- in Palm because the CsrfViewMiddleware did not check the "Origin" header in Django 3.
- in the Studio, because the Studio already runs the CsrfViewMiddleware before
the CorsCSRFMiddleware.
- in the master branch because the master branch does not yet run on
Django 4. But the issue will happen in the master branch without this
proposed change.
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: https://github.com/openedx/wg-build-test-release/issues/325
chore: remove unnecessary logs from the integrated channels
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
