The lti user gets authenticated and logged in as a part of the LTI View
Post. This results in the request user changing during the request. We
mark it here so that it does not produce a false alarm in our
SafeSessions middleware.
Includes:
- general documentation
- links to individual events definitions and location
- adding examples to events docs
- adding annotations at the trigger location
This is intended to silence a rare false positive that seems to happen
when someone logs in on a browser that already has an active session
for another user. We believe there should be no further positives once
this case is handled.
- login and logout views annotate the response to indicate the session
user should be changing between the request and response phases
- safe-sessions middleware skips the verify-user check when this
annotation is present
Also:
- Adds a test around existing behavior for unexpected user-changes
- Remove logging control based on `is_from_log_out`. This reverts most
of af9e26f/PR #11479 for two reasons:
- The safe-sessions `_verify_user` code has since changed to check for
`request.user.id == None`
- A commit later in the PR changes the login and logout pages to
signal that the user/session change is expected
It's being moved to the frontend, to better control when it's
emitted (we want to only emit it if the voucher has not yet been
claimed, which the frontend will ask ecommerce about).
AA-1012
Split modulestore persists data in three MongoDB "collections": course_index (list of courses and the current version of each), structure (outline of the courses, and some XBlock fields), and definition (other XBlock fields). While "structure" and "definition" data can get very large, which is one of the reasons MongoDB was chosen for modulestore, the course index data is very small.
By moving course index data to MySQL / a django model, we get these advantages:
* Full history of changes to the course index data is now preserved
* Includes a django admin view to inspect the list of courses and libraries
* It's much easier to "reset" a corrupted course to a known working state, by using the simple-history revert tools from the django admin.
* The remaining MongoDB collections (structure and definition) are essentially just used as key-value stores of large JSON data structures. This paves the way for future changes that allow migrating courses one at a time from MongoDB to S3, and thus eliminating any use of MongoDB by split modulestore, simplifying the stack.
rest-condition has not been updated for a while, and with DRF 3.9 it is no longer needed since the ability to combine Permission classes using boolean operators is now provided by DRF directly.
- Fixed LANGUAGE_COOKIE settings name to LANGUAGE_COOKIE_NAME beacuse later is recognised by django
- Added test to verify cookies use in dark lang middleware
- Fixing Django 3.0 tests
I had thought this wiki page was publicly accessible, but it
turns out that it is restricted to edX employees. Making the
page publicly visible would involve editing some queries
to remove edX.org-specific information, which is doable but
not something I can commit to right now.
This test was failing for Django 3 and during investigation it found that it isn't working as per expected due to introduction of caching. So fixed the test case to avoid caching to mimic race condition.
BOM-2799
course outline, which don't need block dates below the subsection level of a course.
Pass the course's published version to all the appropriate places where edx-when's API
is called - to allow edx-when to more efficiently cache queried/processed results.
TNL-8061
