fix: fixed the domain issue to point to "courses.edx.org" for the resumeCourseRunUrl
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
adds log for learner data transmission run
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
This switch has been kept disabled in edx.org for well over a year with no
trouble, and the migration to `CLOSEST_CLIENT_IP_FROM_HEADERS`
was introduced in Nutmeg.
DEPR issue: https://github.com/openedx/edx-platform/issues/33733
After refactoring the library_content block to use asynchronous tasks
for syncing and duplicating children, we are seeing an error arise
during library_content duplication process on edx.org:
Traceback (most recent call last):
File "/edx/app/edxapp/edx-platform/openedx/core/djangoapps/content_libraries/tasks.py", line 305, in duplicate_children
_copy_overrides(store=store, user_id=user_id, source_block=source_block, dest_block=dest_block)
File "/edx/app/edxapp/edx-platform/openedx/core/djangoapps/content_libraries/tasks.py", line 383, in _copy_overrides
dest_block=dest_block.runtime.get_block(dest_child_key),
File "/edx/app/edxapp/edx-platform/xmodule/x_module.py", line 1401, in get_block
block = self.load_item(usage_id, for_parent=for_parent)
File "/edx/app/edxapp/edx-platform/xmodule/modulestore/split_mongo/caching_descriptor_system.py", line 127, in _load_item
block_data = self.get_module_data(block_key, course_key)
File "/edx/app/edxapp/edx-platform/xmodule/modulestore/split_mongo/caching_descriptor_system.py", line 154, in get_module_data
raise ItemNotFoundError(block_key)
xmodule.modulestore.exceptions.ItemNotFoundError: BlockKey(...)
We cannot reproduce the issue locally.
We are not entirely certain the cause of this, but we think it might
have do with caching. Specifically, the `store.get_item` and
`source_block.runtime.get_block` methods might use a different cache
than `dest_block.runtime.get_block`. It's possible that writes to
Mongo are sitting in one of those caches, causing reads from the
`dest_block.runtime`'s cache to fail to find dest_block's children.
We attempt to fix this by using the same "block getting" method
consistently. So instead of using a mix of `store.get_item`,
`source_block.runtime.get_block`, and `dest_block.runtime.get_block`,
we just use `store.get_item` everywhere.
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
