The url was renamed from session_language to update_language but it was still referred to in some html templates

…#34404)

Co-authored-by: Dima Alipov <[email protected]>

…ce-4.2.11

chore: update Django to 4.2.11 for Quince - Security Patch

…tadata response

Currently, openedx/frontend-app-authoring#517 faces an issue when the
progress graph toggle is enabled/disabled but the settings are not respected, the disable_progress_graph
attribute will allow the frontend-app-learning repo to use this attribute to respect the settings authored
from frontend-app-course-authoring and ultimately fix openedx/frontend-app-authoring#517.

…s-graph

feat: Adds disable_progress_graph attribute to the returned course_me…

…nedx#34485)

Co-authored-by: Dima Alipov <[email protected]>

* fix: Social link parsing approach changed

* fix: fix tests

* fix: better approach

…enedx#34466)

"Course organization display string" option in Advanced settings
doesn't influence certificate.

Co-authored-by: Dima Alipov <[email protected]>

… discussion is enabled (openedx#34426)

Co-authored-by: Jason Wesson <[email protected]>

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.