This version contains necessary fixes for validating the "audience"
component of the JWT, as seen in ARCHBOM-1281. (I believe we'll need to
pass both the App ID and the Service ID in an additional AUDIENCE "other
settings" key for this third-party-auth backend.)
Vendored from version 3.4.0 (9d93069564a60495e0ebd697b33e16fcff14195b)
social-core:
https://github.com/python-social-auth/social-core/blob/3.4.0/social_core/backends/apple.py
v3.4.0 is unreleased at this time (2020-07-28) and contains several
necessary bugfixes over 3.3.3 for AppleID, but also causes the
TestShibIntegrationTest.test_full_pipeline_succeeds_for_unlinking_testshib_account
test in common/djangoapps/third_party_auth/tests/specs/test_testshib.py
to break (somehow related to social-core's change 561642bf which makes
a bugfix to partial pipeline cleaning). ARCHBOM-1389 filed to address
this at our convenience.
Note: 3.4.0 was not released to PyPI due to a broken test, so we might
see a 3.4.1 when it's actually released:
https://github.com/python-social-auth/social-core/issues/485
This also has an initial use case for Personalized Learner Schedules
to add CTAs to capa and vertical blocks to allow users to shift their
course deadlines.
This reverts commit 06e04eff8c.
Omitting the course_key argument to ExperimentWaffleFlag.is_enabled
causes a 500 when the underlying experiment flag is enabled.
TNL-7405
We noticed that since users can choose to reset their due dates,
they would have the ability to let due dates pass and then for any
assessment that allows viewing the answer after the due date would be
visible. The user could thus view all answers and then reset their
due dates to receive a perfect score.
This PR works to fix that issue by changing all show answer values
to not take into account being past the due date when inside a PLS
course.
This is for the frontend-app-learning MFE to consume and show an
alert when offer_html is defined.
I've also tweaked that html a bit to work better in an environment
that doesn't have LMS's exact css.
Fix issue with `SameSite=None` cookies from being blocked when `django_cookies_samesite.middleware.CookiesSameSite` is enabled for `devstack_docker` environment.
Set `SESSION_COOKIE_SAMESITE=Lax` for `devstack_docker` environment by default to allow login to LMS service. This is a fix for `devstack_docker` default value set to `Lax` for `DCS_SESSION_COOKIE_SAMESITE`. It was defaulting to `SameSite=None` which requires a secure site which `localhost` site does not by default. Setting this `SameSite` cookie attribute to something other than `None` will continue to allow login to the LMS for `devstack_docker` environment. Regards to #23671 and https://discuss.openedx.org/t/lti-xblock-and-samesite/759/16