Deleting all instances of the path from the URL meant that referers like
`https://learning.edx.org/` were turned into `https:learning.edx.org`. The
solution here is to use `urlunparse` to put the URL back together, but only
with the desired components (scheme and authority/netloc).
This relates to our previous upgrade to django-cors-headers 3.x, which
changed to use origins instead of domains in its whitelist setting:
36df86d829 (diff-811d60a3e1d60ff694eace0242e77d6b810d8e9c63c36d7b3c2591a08ebbb94bR58)
Added regression test (fails on master, passes on branch.)
Also:
- Replace word "domain" with "origin" in few places to use the correct
term. (We should probably change this more broadly in names and comments
in this module as some point.)
- Simplify logging to just output what we know, and not try to recapitulate
the logic too much.
ref: BOM-2961
* fix!: Removes the openedx provider temporarily
UI changes to support the new provider are in progress. Once they are ready we
can add back this provider.
* feat: add support for hiding providers from the API response
Contingent on new feature toggle `VERIFY_USER_CHANGE_UNCONDITIONAL`, check
for request/response user mismatches on all requests, not just those
setting a session cookie on the response.
This is intended to *restore* an older behavior. I believe that almost all
requests used to set a new session cookie, and for some reason no longer
do, so this is really just an attempt to return to that previous behavior
no matter whether a new session cookie will be set. (Previously, the
cookie-to-be-deleted check would still have been in effect, so this is
actually a slight change from the earlier behavior -- the logout response
will now be included, and then quickly ignored due to a later check.)
The off-by-default switch moves several lines of code out of a try block,
but also out from under an if guard that checks for certain cookie
conditions. The movement out of the try block should be irrelevant, since
neither of the relocated lines should be raising a SafeCookieError.
However, there is some chance that they could raise other exceptions when
called from their new location (and new situations), hence the use of a
feature toggle -- we'll want to make it easy to switch the new behavior off
quickly if we start seeing an increase in errors.
Once the change is well-exercised, we can remove the toggle and the old
call locations.
I'm not entirely sure about the change to the `verify_error` utility
function in the unit tests, but it seems like even unauthenticated requests
in Django end up with a user and session on the request object, so this is
probably a close-enough way to mock that out.
I duplicated a couple of tests to test with feature toggle on/off.
ref: ARCHBOM-1952
* feat: Adds a new discussion topic configuration mechanism
The new discussion configuration system links discussion topics directly to the course structure. This change adds a new task that sends a discussion update signal if there are any changes to the course. This signal includes all the context needed to update the configuration of the course.
The handler for this new event will create a new entry for each unit that needs a topic in the database. In the future this will be used to see the topics in the course.
* fix: add support for marking a provider as supporting LTI
* fix: review feedback
* chore: update deprecated import from collections
* chore: remove outdated imports from markdown library
as it hasn't been supported since 2.0.3 and we're on 3.x.
This was deprecated at least as early as 2012!
* docs: add docstring and remove lint-amnesty to markdown plugin
* chore: remove deprecated etree import
* style: remove unnecessary-comprehension for sets
* style: resolve a number of amnestied pylint complaints
Co-authored-by: stvn <stvn@mit.edu>
* fix: use pngs for the goal reminder email banner and remove redundant unsubscribe link
* fix: update
* fix: Miscellaneous UI fixes and fixed unsubscribe link
in favor of the added MakoSystem render_template method.
Related changes:
* Adds the MakoService to the StudioEditModuleRuntime,
PreviewModuleSystem, LmsModuleSystem, and XBlockRuntime
* MakoService constructor takes a `namespace_prefix` string, so that the
CMS PreviewModuleSystem can render to LMS templates, without needing
the special render_from_lms helper method.
* ModuleSystem.render_template becomes a read-only property, so the
constructor calls and test module systems are updated accordingly.
* Adds tests for the MakoService and module system shims.
- Add early exit for readability. Less indentation here may make the control flow easier to read.
- Wrap debug info generation in error-suppressing try-except block.
Co-authored-by: Robert Raposa <rraposa@edx.org>
Add logging in case a safe-session user mismatch is related to wrong
session being retrieved from cache. This additional logging should
reveal any such mismatch (without revealing the actual session ID in
logs).
Send to metrics as custom attributes as well.
Also:
- Compute "session_id_changed" based on all three session IDs (and
send as custom attribute)
- Put all _verify_user logs into one (multiline) log line
- Accordingly, change logging assertion to only require a substring,
at-least-once match rather than a full-and-only match.
ref: ARCHBOM-1939
The following ModuleSystem attributes are deprecated by this change, and should be pulled directly from the user service instead:
* anonymous_student_id
* seed
* user_id
* user_is_staff
Related changes:
* Removes the `user` and `anonymous_student_id` parameters from the ModuleService constructor.
* Stores anonymous_user_id in XBlockDjangoUserService's opt_attr
* Pulls out constants used by DjangoXBlockUserService opt_attr so they can be used in the platform code.
* LmsModuleSystem uses the user service created in wrapper function for runtime.publish to avoid requiring the user
service to be "needed" by all XBlocks.
* LmsModuleSystem no longer checks for instances of XModuleDescriptor when deciding what kind of anonymous_user_id to
provide: all XModules are XBlocks, so this check is unnecessary.
* XBlockRuntime returns a user service when requested
* Adds tests for deprecated ModuleSystem attributes and changes to XBlockDjangoUserService.
(cherry picked from commit c41e7fb93a)
The VERIFIED_NAME_FLAG, the VerifiedNameEnabledView, and the verified_name_enabled key removed from responses for both VerifiedNameView view and VerifiedNameHistoryView
were removed as part https://github.com/edx/edx-name-affirmation/pull/12. This was released in version 2.0.0 of the edx-name-affirmation PyPI package. Please see below for additional context for the removal, copied from the name-affirmation commit message.
The VERIFIED_NAME_FLAG was added as part https://github.com/edx/edx-name-affirmation/pull/12, [MST-801](https://openedx.atlassian.net/browse/MST-801) in order to control the release of the Verified Name project. It was used for a phased roll out by percentage of users.
The release reached a percentage of 50% before it was observed that, due to the way percentage roll out works in django-waffle, the code to create or update VerifiedName records was not working properly. The code was written such that any change to a SoftwareSecurePhotoVerification model instance sent a signal, which was received and handled by the Name Affirmation application. If the VERIFIED_NAME_FLAG was on for the requesting user, a Celery task was launched from the Name Affirmation application to perform the creation of or update to the appropriate VerifiedName model instances based on the verify_student application signal. However, we observed that when SoftwareSecurePhotoVerification records were moved into the "created" or "ready" status, a Celery task in Name Affirmation was created, but when SoftwareSecurePhotoVerification records were moved into the "submitted" status, the corresponding Celery task in Name Affirmation was not created. This caused VerifiedName records to stay in the "pending" state.
The django-waffle waffle flag used by the edx-toggle library implements percentage rollout by setting a cookie in a learner's browser session to assign them to the enabled or disabled group.
It turns out that the code that submits a SoftwareSecurePhotoVerification record, which moves it into the "submitted" state, happens as part of a Celery task in the verify_student application in the edx-platform. Therefore, we believe that because there is no request object in a Celery task, the edx-toggle code is defaulting to the case where there is no request object. In this case, the code checks whether the flag is enabled for everyone when determining whether the flag is enabled. Because of the percentage rollout (i.e. waffle flag not enabled for everyone), the Celery task in Name Affirmation is not created. This behavior was confirmed by logging added as part of https://github.com/edx/edx-name-affirmation/pull/62.
We have determined that we do not need the waffle flag, as we are comfortable that enabling the waffle flag for everyone will fix the issue and are comfortable releasing the feature to all users. For this reason, we are removing references to the flag.
[MST-1130](https://openedx.atlassian.net/browse/MST-1130)
Also:
- Normalize response of a helper function to always be a boolean
- Make unit test accepting of unrelated custom attr calls
ref: ARCHBOM-1939, ARCHBOM-1941
BREAKING CHANGE: Removed unused and misleading custom attributes
used for monitoring:
* `jwt_expires_in`: Removed because it is constant for all requests
and just repeating the setting value. It was also misleading.
* `jwt_is_asymmetric`: Removed because multiple JWTs might be created,
and only the last would be reported, which is misleading. This was
meant to help with a future project to get everyone on to asymmetric
JWTs, but can be added when needed, and probably should ONLY monitor
deprecated (symmetric) usage that needs to be fixed. That can be left
for another day.
* feat: Adds discussions settings for new discusions experience
This commit adds new discussions settings for the new discussions experience. These are stored in the course so they can be a part of course import/export flow.
These are also added to the discussions configuraiton API to allow MFEs to update the settings.
The discussions API is currently available via LMS, however that means it cannot save changes to the modulestore. This also adds the API to the studio config so it can now also be accessed from studio and be used to save course settings.
* fix: tests
This commit adds new discussions settings for the new discussions experience. These are stored in the course so they can be a part of course import/export flow.
These are also added to the discussions configuraiton API to allow MFEs to update the settings.
The discussions API is currently available via LMS, however that means it cannot save changes to the modulestore. This also adds the API to the studio config so it can now also be accessed from studio and be used to save course settings.
