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.
* Deprecates ModuleSystem can_execute_unsafe_code, get_python_lib_zip and cache properties
* Adds a new CacheService and SandboxService to provide the deprecated property
* Adds tests for the added CacheService and SandboxService
* Updates the ModuleSystemShim tests in Lms and Studio
* feat: Created API for programs live page zoom lti
* refactor: Merged similar code by inheritance
* refactor: removed duplicates and resolved tight coupling issues
* refactor: Decoupled views
when fetching block metadata and rendering blocks while maintaining the
original usage IDs/OLX.
This change is marked temporary because LabXchange need it during the
transition to a custom runtime, but it's not really useful to anyone
else. We will revert this change with a future PR.
feat: AA-1138: Adds ability to have Weekly Goal Celebration Modal in MFE
Adds celebrate_weekly_goal to the CourseEnrollmentCelebration and includes logic
for only returning True if the db field is true and the learner has hit their goal
this week. Adds ability to set to false via the API already used by the frontend.
Default db value is False, but all new enrollments after merge will be set to True.
Adds celebrate_weekly_goal to the CourseEnrollmentCelebration and includes logic
for only returning True if the db field is true and the learner has hit their goal
this week. Adds ability to set to false via the API already used by the frontend.
Default db value is False, but all new enrollments after merge will be set to True.
* feat: [AA-922] remove deprecated Goals backend
While the new Weekly Learning Goals were being rolled out, the previous goal setting feature still existed behind a waffle flag.
The Weekly Learning Goals now become the one and only learning goal feature.
This change does not remove the old goals feature from the legacy backend, and therefore it does not remove any of the data that was used by the old goals feature.
The goals are now driven by the single pre-existing Waffle flag ENABLE_COURSE_GOALS
- Removed COURSE_GOALS_NUMBER_OF_DAYS_GOALS waffle flag, replacing it where needed with the existing ENABLE_COURSE_GOALS
- modified the API to remove the old goal_options, keeping the redundant weekly_learning_goal_enabled flag
- updated tests
- refactor tests to fit 50 line limit in lint
* fix: safe session bug when request has no user
Fixes a bug during safe session monitoring when
request has no user.
ARCHBOM-1940
* fixup! add comment and loosen if condition
Using a single query to get a user using both username and email fields
generates a massive `key_len` and causes DB overload. Separated these
lookups into two separate queries.
VAN-819
Fixes a bug where a custom attribute was being set
even for cases where we did not have the appropriate
data, and an exception was being raised.
ARCHBOM-1940
* add custom attribute for list of user ids on mismatch.
* log request header for all mismatched users for all
requests for N seconds after the mismatch is found, if
LOG_REQUEST_USER_CHANGE_HEADERS is enabled. See toggle
docs for more details.
ARCHBOM-1940
If the sequence metadata view is asked to give metadata for a block
that is not a sequence (or section), give a proper http code back,
rather than throwing an attribute exception.
This avoids a monitoring error being flagged, and lets the frontend
catch this case specially (which the MFE does do, to notice that it
actually has a unit, not a sequence).
* feat: add api mapping to get comments by course+user
fix: merge the new user comments API by overloading the thread comments API
fix: handle endorsements and fix broken tests
fix: improve the view documentation
fix: unused imports
fix: restrict flagged filter to privileged users
fix: validate course_id properly
* fix: add docstring to the retrieve_all method
Previously, it had some basic manual masquerading by calling the
endpoint with ?user=mytestuser. But this adds standard session
masquerading support to the endpoint as well.
This support is limited by LS's own partition group support. It
only looks at the enrollment track partition currently. Further
FBE and cohort partition support will come later.
But this commit opens up normal session masquerading for:
- Generic student
- Specific student
- Enrollment track
AA-1151
The _does_name_change_require_verification(user_profile, old_name, new_name) method of the accounts user_api determines whether a learner can change their name from old_name to new_name. Originally, it delegated solely to the NameChangeValidator class of the edx-name-affirmation API, which ran a set of checks against the name change. One of said checks was asserting that learners with one or more certificates could not change their name without completing IDV.
This pull request changes this behavior.
Learners may have certificates that are not in a passable status (e.g. "unverified"). We only want to require IDV for name changes for learners that have passing statuses. The existing code prevented learners from changing their name if they had any certificates at all, irrespective of the certificate status. This change only considers certificates in a passable status.
Additionally, learners may have certificates and also not be enrolled in any "verified" seats. For example, despite edX no longer offering "honor" seats, learners may have enrollments in "honor" modes, which grant certificates but are not considered "verified" enrollment modes. IDV requires that a learner be enrolled in a "verified" seat in order to complete IDV. Prior to this change, learners that were navigated to IDV to validate a name change were unable to complete IDV. This change introduce a check that a learner is in a "verified" mode in addition to using the NameChangeValidator. This prevents the account MFE from navigating an IDV-ineligible learner to IDV.
MST-1254: https://openedx.atlassian.net/browse/MST-1254
The language cookie "samesite" attribute was always set to "None", even in
non-secure environments, such as the devstack. This was causing client-side
warnings in non-https environments, and the language cookie was not properly
set.
