Datadog was removed 6+ years ago but some settings and related keys got
left behind. Get rid of them since we don't need them and also to
prevent people from assuming it's okay to hardcode datadog settings into
our codebase.
BREAKING CHANGE: Removes all code, tests, and settings related to
indexing of V2 (blockstore-backed) content libraries in elasticsearch.
This includes indexing of top-level library metadata as well as indexing
of library block metadata. Operators who enabled the experimental
Library Authoring MFE *and* the experimental ENABLE_CONTENT_LIBRARY_INDEX
feature may notice that sorting, filtering, and searching of V2
libraries and their blocks may now be slower and/or less powerful.
The ENABLE_CONTENT_LIBRARY_INDEX feature was already disabled by
default, so most/all operators (including edx.org) should not notice
any difference.
Removed settings include:
* FEATURES['ENABLE_CONTENT_LIBRARY_INDEX']
* ENABLE_ELASTICSEARCH_FOR_TESTS
* TEST_ELASTICSEARCH_USE_SSL
* TEST_ELASTICSEARCH_HOST
* TEST_ELASTICSEARCH_PORT
For rationale, see the updated "Status" section of:
./openedx/core/djangoapps/content_libraries/docs/decisions/0001-index-libraries-in-elasticsearch.rst
Originally, Blockstore was an independent micro-service, accessed via a REST API.
Then, we changed Blockstore so it could be installed as an in-process Django app.
To support both modes, there existed a blockstore_api wrapper library in edx-platform,
with toggles controlling whether the wrapper called out to the micro-service's REST API versus the
Django app's Python API. Now that the micro-service Blockstore implementation is deprecated,
though, this wrapper library and toggles are just unnecessary complexity.
As a first step towards cleanup, we:
* remove several toggles and settings (details below);
* remove the blocokstore_api wrapper methods which called the REST API and
marshalled them back into Python objects; and
* remove all test cases which relied on the Blockstore micro-service (and were skippped in CI).
In the future, we will remove the content libraries indexer,
clean up the remaining bits of blockstore_api, and flatten out all
the Blockstore-related test class hierarchies which are no longer nceessary.
BREAKING CHANGE:
* These Django settings are removed:
* BLOCKSTORE_PUBLIC_URL_ROOT
* BLOCKSTORE_API_URL
* BLOCKSTORE_API_AUTH_TOKEN
* BLOCKSTORE_USE_BLOCKSTORE_APP_API
* The blockstore.use_blockstore_app_api Waffle switch is removed.
* edx-platform will act as it did when the DJango setting BLOCKSTORE_USE_BLOCKSTORE_APP_API
or the Waffle switch blockstore.use_blockstore_app_api were enabled. That is, any running Blockstore
micro-service instance will be ignored, and the Blockstore package which is installed into edx-platform
will be used instead.
Ref: https://github.com/openedx/blockstore/issues/296
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
Refactors and reworks the LibraryContentBlock so that its
sync-from-library operations are asynchronous and work with
V2 content libraries. This also required us to make
library_content block duplication asynchronous, as that
involves syncing from the source library.
For the sake of clarity, this PR includes two major method renames:
* update_children(...) -> sync_from_library(...)
* refresh_library(...) -> sync_from_library(upgrade_to_latest=True, ...)
an an XBlock HTTP handler rename:
/refresh_children -> /upgrade_and_sync
There are still a couple issues with import or duplication
of library_content blocks referencing V2 libraries other than
latest. These will be resolved in an upcoming PR.
Part of: https://openedx.atlassian.net/wiki/spaces/COMM/pages/3820617729/Spec+Memo+Content+Library+Authoring+Experience+V2
Follow-up work: https://github.com/openedx/edx-platform/issues/33640
Co-authored-by: Connor Haugh <chaugh@2u.com>
Co-authored-by: Eugene Dyudyunov <evgen.dyudyunov@raccoongang.com>
With this change, the platform users who access content via LTI will be
automatically linked to their platform account instead of the new (anonymous)
one. The following conditions need to be met:
* The `LtiConsumer` should be configured to auto-link the users via email.
* The LTI Consumer should share the user's email using the
`lis_person_contact_email_primary` parameter in the LTI Launch POST data.
This also replaces the one-to-one relationship of the `User` and `LtiUser`
with one-to-many. This way, multiple `LtiUser` objects can refer to the same
`edx_user`. With the auto-linking, multiple LTI Consumers can create
independent `LtiUser` objects with the same `edx_user`.
Co-authored-by: Piotr Surowiec <piotr@surowiec.it>
This flag was introduced to gate the rollout of moving the UI component for proctoring settings into the pages and resources view and was never cleaned up. At this point we should always be linking the the new page for proctoring settings.
When including `JwtAuthentication`, the auth_header becomes `JWT
realm="api"`. Without it, it is `None`. This changes the behavior of the
code in DRF and returns a slightly different auth response.
Relevant Code: 56946fac8f/rest_framework/views.py (L456C3-L456C3)
By default DRF sets 'DEFAULT_AUTHENTICATION_CLASSES' to:
```
[
'rest_framework.authentication.SessionAuthentication',
'rest_framework.authentication.BasicAuthentication'
]
```
We also want to allow for JWT Authentication as a valid default auth
choice. This will allow users to send JWT tokens in the authorization
header to any existing API endpoints and access them. If any APIs have
set custom authentication classes, this will not override that.
I believe this is a fairly safe change to make since it only adds one
authentication class and does not impact authorization of any of the
endpoints that might be affected.
Note: This change changes the default for both the LMS and CMS because
`cms/envs/common.py` imports this value from the LMS.
BREAKING CHANGE: For any affected endpoint that also required the user
to be authenticated, the endpoint will now return a 401 in place of a
403 when the user is not authenticated.
- See [these DRF docs](https://github.com/encode/django-rest-framework/blob/master/docs/api-guide/authentication.md#unauthorized-and-forbidden-responses) for a deeper explanation about why this changes.
- Here is [an example endpoint](b8ecfed67d/openedx/core/djangoapps/embargo/views.py (L20-L21)) that does not override defaults and checks for IsAuthenticated.
Generally speaking, this is should not be a problem. An issue would
appear only if the caller of the endpoint is specifically handling 403s
in a way that would be missed for 401s.
