This should really be all we need for most cases, and we don't want to
emit sensitive data more than necessary, even encrypted. If we need to
inspect one cookie in particular, we can add special logging for that.
Also, change to greater-than-or-equal for threshold to match setting docs.
ref: ARCHBOM-2042
Convert more tests from MONGO_AMNESTY to SPLIT modulestores.
This is in preparation for just wholesale denying access to Old
Mongo, so I either converted tests to split or just deleted some
test variants that were Old Mongo specific. (e.g. ddt lines)
It's likely that someone will at some point enable encrypted logging but
forget to deploy the config change that sets the key; if this happens, we
should gracefully return a warning rather than raise an exception.
Along the same lines, make sure that safe-sessions won't raise an exception
if the setting is missing, and document the suggested use of getattr.
It's long past time that the default test modulestore was Split,
instead of Old Mongo. This commit switches the default store and
fixes some tests that now fail:
- Tests that didn't expect MFE to be enabled (because we don't
enable MFE for Old Mongo) - opt out of MFE for those
- Tests that hardcoded old key string formats
- Lots of other random little differences
In many places, I didn't spend much time trying to figure out how to
properly fix the test, and instead just set the modulestore to Old
Mongo.
For those tests that I didn't spend time investigating, I've set
the modulestore to TEST_DATA_MONGO_AMNESTY_MODULESTORE - search for
that string to find further work.
- test: Remove reference to `REDIRECT_TO_LOGIN_ON_SAFE_SESSION_AUTH_FAILURE`,
since it was removed in commit bd7653aefcd77a/PR #29132.
- docs: Clarify what "work correctly" means for header-logging
This is more correct and may reduce the likelihood of perpetuating a bad
mixed-auth state.
In general, we should probably be modifying session and JWT cookies in
sync at all times, never individually. This specific code probably won't
make anything worse, but a clean reset might improve user experience in
the rare cases where someone somehow gets their browser into a weird
state.
- Switch from `response.set_cookie` with past expiry to just using the
`response.delete_cookie` method.
- Docstring improvements.
ref: ARCHBOM-2030 (internal)
- Adds Enhanced Staff Grader (ESG) backend-for-frontend (BFF) in `lms/djangoapps/ora_staff_grader`
- Adds routing to ESG BFF at `{lms_url}/api/ora_staff_grader/*`
- Adds mock implementation routing at `{lms_url}/api/ora_staff_grader/mock/*`
- Adds `ORA_GRADING_MICROFRONTEND_URL` setting for routing to ESG microfrontend (MFE)
- Updates to the teams app:
- Add`get_teams_in_teamset` to the teams API.
- Add `get_team_names` to teams service.
- Adds `openassessment.staffgrader` app for appropriate ORA migrations.
- Modifies management commands for creation of users.
- Updates test factory to return display org with course overview.
Co-authored-by: jansenk <jkantor@edx.org>
Co-authored-by: Leangseu Kim <lkim@edx.org>
Co-authored-by: Ben Warzeski <bwarzeski@edx.org>
* feat: New API for discussion topics
Creates a new API for discussion topics that uses auto-crated discussion topic links for the new discussion provider.
* squash!: refresh migration
If a learner changes modes (like upgrades to a verified learner),
we will reset their schedule for them. But if they did this before
the course started, we would accidentally set their schedule to
the current time. So when the course did start, they would already
appear to be behind schedule.
That's silly. So now we always look at course start time when
resetting the learner's schedule.
AA-426
This drops the learning_sequences.use_for_outlines waffle flag,
enabling using learning sequence outlines unconditionally.
(Note that Learning sequences still don't support legacy keys.)
AA-1040
The course outline view has a way for a staff user to make a request as if
they are another user, not just by using the masquerade mechanism but also
by setting a request parameter. This can result in false positives in the
safe-sessions middleware, and if `ENFORCE_SAFE_SESSIONS` is enabled the
responses will be 401 errors.
The fix here is to do the same thing that masquerading does in setting a
`real_user` property on the new user object, which the safe-sessions
middleware then undoes (restoring the request.user) before determing
whether there's a mismatch.
(Without this fix, enabling `ENFORCE_SAFE_SESSIONS` also causes some tests
in `test_views.py` to fail.)
Using the same Client or APIClient instance for multiple users, where
one user has an active session and the other is making an
Authorization header call, results in a Safe Sessions violation.
By using separate clients for different test users, we avoid this
violation, allowing `ENFORCE_SAFE_SESSIONS` to be enabled by default.
Change `mark_user_change_as_expected` to no longer take the response object
and instead convey the expected-change information via RequestCache.
This requires edx-django-utils 4.4.2, which fixes the bug where
RequestCache was cleared in the exception phase.
Also, no longer mark `ENFORCE_SAFE_SESSIONS` toggle as
temporary. We'll want it as an opt-out.
I was tempted to take this opportunity to move any existing
`mark_user_change_as_expected` calls to be closer to where the actual
change request.user occurs, reducing risk of both false positives and false
negatives, but it would be better to do that one at a time in case a move
breaks something. (Ideally it would be called right after any
`django.contrib.auth` `login` or `logout` call; previously, we were
constrained by having to make the call after a response object had been
created.) These changes can be made later if it becomes necessary.
