Open edX implements its a JwtAuthentication class in edx-drf-extensions
(in edx_rest_framework_extensions.auth.jwt.authentication). This class
updates the local User database entry to match certain values in the
token. It's used as a way to automatically provision and update users
with their LMS user information on other Open edX services like
ecommerce.
Since LMS and Studio keep the record of truth in its database tables,
they should *not* update their database user information based on the
JWT. Doing so would allow stale JWTs to incorrectly reset user values
after they had been changed in the LMS. This is done by having the
EDX_DRF_EXTENSIONS['JWT_PAYLOAD_USER_ATTRIBUTE_MAPPING'] setting be an
empty dictionary, and was set correctly for the LMS in its common.py env
settings module. Unfortunately, this was *not* being set for Studio.
This commit adds the same setting to Studio's common settings module.
Prior to this commit, it was possible for a stale JWT to reset user
attributes if the user hit a Studio API endpoint that used JWT for auth
(e.g. endpoints used by the Course Authoring MFE). This opened up a
potential security issue where a global staff user (is_staff=True) that
had their global staff status removed (is_staff=False) could have up to
a one hour window in which they could use their stale-but-still-valid
global-staff JWT token to regain global staff status by calling a Studio
endpoint with their browser.
[APER-3241]
This PR updates the retirement pipeline to purge learners' names from certificate records when their account is being retired.
It also introduces a new management command that can be used by Open edX operators to purge the leftover name data (PII data) from the `certificates_generatedcertificate` table. This is designed as a one-time use data fixup, as the retirement functionality should clean this moving forward.
Note: I had originally implemented this as a `warnings.warn()` call
directly in lms/envs/devstack.py and cms/envs/devstack.py, but for
whatever reason, those warnings were getting swallowed. System checks
display more prominently, anyway.
Part of: https://github.com/openedx/public-engineering/issues/247
Blockstore and all of its (experimental) functionality has been replaced with
openedx-learning, aka "Learning Core". This commit uninstalls the now-unused
openedx-blockstore package and removes all dangling references to it.
Note: This also removes the `copy_library_from_v1_to_v2` management command,
which has been broken ever since we switched from Blockstore to Learning Core.
Part of this DEPR: https://github.com/openedx/public-engineering/issues/238
enterprise version bump 4.17.6
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
Introduce emission of the COURSE_PASSING_STATUS_UPDATED as well as CCX_COURSE_PASSING_STATUS_UPDATED events, that are groundwork for the new Credly integration and the future badging initiative.
Product GH ticket for tracking - openedx/platform-roadmap#280
* feat: make tagging feature enabled by default
* fix: use the correct flag for tagging enabled
* fix: make compatible with other changes from master
* fix: more compatibility fixes
* fix: show tag counts at all levels of the outline, not just units
* chore: typo
* test: fix counts in test suite now that tagging is on by default
---------
Co-authored-by: Braden MacDonald <braden@opencraft.com>
Co-authored-by: Yusuf Musleh <yusuf@opencraft.com>
The test count was off because without warnings disabled, it was also
counting warning lines as tests.
The `head -n -2` grabs everything but the last two lines which contain a
count (not sure why this isn't used). If you run without
`--disable-warnings` this will include any warnings that occur during
test collection which we don't want in this case.
The LMS and Studio need to set values for CORS_ALLOW_HEADERS so that the
MFEs can work properly, since preflight requests will need to send over
extra headers. Prior to this commit, CORS_ALLOW_HEADERS was being
redefined in multiple places in edx-platform and again in Tutor's config
because it was only being conditionally set if ENABLE_CORS_HEADERS was
True (which was a policy setting). But CORS_ALLOW_HEADERS is application
logic in that the value is determined by what the view needs, and won't
vary by deployment.
By consolidating this to always be defined in the common.py files, we
make sure that deployment environments don't have to define it. An
example of where this bit us was when course import in the course
authoring MFE did not work because Tutor was using an outdated value for
this setting.
A followup to this would be to just rip out the ENABLE_CORS_HEADERS
setting entirely, and just always have it on. But that would benefit
from a little more discovery to make sure there's no weird use case that
still requires it to be False (maybe something in the test suite?).
