This commit enables sharing username and email in LTI 1.3 basic launches.

This commit adds preferred_username and email as attributes of the Lti1p3LaunchData. The application or context that instantiates Lti1p3LaunchData is responsible for ensuring that username and email can be sent via an LTI 1.3 launch and supplying these data, if appropriate.

This commit sends username and email as part of an LTI 1.3 basic launch when the XBlock fields ask_to_send_username and ask_to_send_email are set to True, respectively.

Code was also added to block the transmission of username and email in both LTI 1.1 and LTI 1.3 launches if the value of the lti_access_to_learners_editable method of the LTI configuration service (i.e. the value of the CourseAllowPIISharingInLTIFlag ConfigurationModel) returns False, as originally intended and documented in the "Unified Flag for Enabling Sharing of PII in LTI
" decision record. However, the LTI configuration service is not currently available or defined in all runtime contexts, so this behavior only works when editing the XBlock in Studio (i.e. the studio_view). It does not work from the XBlock preview in Studio (i.e. the author_view) or from the LMS (i.e. the student_view).

The impact of this is that the ask_to_send_username and ask_to_send_email fields will be hidden in LTI XBlocks in courses for which an instance of the CourseAllowPIISharingInLTIFlag ConfigurationModel does not exist or for which an existing instance of the CourseAllowPIISharingInLTIFlag ConfigurationModel is disabled. If there already exists an instance of the CourseAllowPIISharingInLTIFlag ConfigurationModel for a course, then disabling the flag will only hide the ask_to_send_username and ask_to_send_email in the LTI XBlock edit menu. It will not prevent the transmission of username or email via the launch in Studio preview or via the launch in the LMS. If a course has already set ask_to_send_username or ask_to_send_email to True in the XBlock edit menu, that information will continue to be sent via the LTI 1.1 or LTI 1.3 launch.

We plan to fix this bug in the future.

This commit fixes a bug in the way that the the form_url is used in the Javascript.

For LTI modal launches in the courseware microfrontend (MFE), the Javascript prepends the value of window.location.origin to the form_url when sending a message via postMessage to window.parent.

This is because the form_url included in the template by the XBlock handler does not include a port and hostname for LTI 1.1 launches.

In LTI 1.3, however, the form_url should include the port and hostname, because it's user input (e.g. fields on the XBlock). Because of this, LTI 1.3 modal launches do not work, because the Javascript appends a port and hostname to a URL that already has a port and hostname, resulting in something like "http://localhost:18000http//localhost..."

This commit changes the way that the launch URL is calculated by the Javascript. The version of LTI being used is included in the template by the Python code, which is read by the Javascript. The Javascript then adds the port and hostname for LTI 1.1 form URLs but not for LTI 1.1 form URLs.

This commit removes the request_cached decorator on the method lti_access_to_learners_editable. The caching was not working correctly. It appeared that the cached value was not being recomputed on a per-request basis, which meant that the cached value was not successfully being updated. Also, the initial cached value was computed incorrectly. The effect was that the PII sharing XBlock fields were always being displayed in Studio and CourseAllowPIISharingInLTIFlag instances were not being created for courses that had PII sharing XBlocks that did not already have CourseAllowPIISharingInLTIFlag instances.

Note that this commit fixes the backwards compatibility of the CourseAllowPIISharingInLTIFlag. This means that CourseAllowPIISharingInLTIFlag will now be created for all courses that contain an LTI XBlock that shares username and/or email for which a CourseAllowPIISharingInLTIFlag does not already exist.

Time was spent on determining why the caching was failing, but it was challenging. If the issue is in the request_cached decorator, then the impact of changing it is large - it's used elsewhere in the platform. The need for a fix was urgent, and the supposed performance enhancement of leaving the caching in doesn't justify delaying a fix.

This commit replaces the consent modal that appears before personally identifiable information (PII) is shared via an LTI launch with an inline consent dialog. The consent dialog better supports the three LTI launch types (i.e. inline, modal, and new_window). This commit also fixes a bug where the PII consent modal was not being displayed for inline or modal launches.

We would like to enable PII in an LTI1.3 launch but turning that flag on would allow the tool to grab PII for the entire course roster via NRPS. We have not fully evaluated the privacy concerns if that is allowed. For the time being this platform setting can wholly disable PII over NRPS to avoid the issue

build: Remove community-engineering CODEOWNERS

Team no longer exists. See <https://github.com/edx/edx-arch-experiments/issues/132>.

docs: manually testing LTI 1.1 Basic Outcomes Service 1.0 and LTI 2.0 Result Service

Python Requirements Update

* fix: remove lms specific waffle check

Fix LTI 1.1 Basic Outcomes Service and LTI 2.0 Rsult Service to Support External User IDs

In #307, we added the ability to send a stable, static user identifier (i.e. external user ID) to fix failed launches with the QwikLabs tool. This is because the QwikLabs tool did not work with the course-anonymized user IDs we used to send (i.e. anonymous user IDs). Inadvertently, this change broke the LTI 1.1 Basic Outcomes Service and the LTI 2.0 Result Service for courses that use the external user ID (i.e. they have the lti_consumer.enable_external_user_id_1p1_launches CourseWaffleFlag enabled). The Basic Outcomes Service and Result Service handle grade pass backs. Because we now have two ways to identify a user in LTI 1.1/2.0, we must update the Basic Outcomes Service and Result Service to support both. This commit fixes this bug.

fix: do not attempt to load the block just to look at the location

the block is not loadable in exams so clean fails in that IDA, but
we shouldn't need the block to ask a question about the course

refactor: replace deprecated `rebind_noauth_module_to_user`, `get_real_user`, `runtime.hostname`, `runtime.course_id` [BD-13]

Replaces usages of runtime.course_id with runtime.scope_ids.usage_id.context_key.

The hostname used to construct the resource link ID is moved from using
a runtime attribute to the LMS_BASE setting.

The `rebind_noauth_module_to_user` function is deprecated in the core
edx-platform [1]. This is now replaced with a "rebind_user" service.
This commit brings this change to the LTI Consumer XBlock.

[1] - https://github.com/openedx/edx-platform/pull/30320/

The OAuthlib 1.0 Client's get_oauth_params fails when processing Webob
request object with the body stored as a binary instead of string.
This commit replaces the client function with a different one which
doesn't involve body hashing, as the body hash is calculated explicitly.

Fix github url strings (org edx -> openedx)

Add course flag to send external_user_id as user_id in LTI 1.1 XBlock launches

This commit introduces a new CourseWaffleFlag lti_consumer.enable_external_user_id_1p1_launches. When this flag is enabled for a course, LTI 1.1 XBlock launches in that course will send the user's external_user_id as the user_id attribute of the launch. external_user_id is the user's external user ID as defined, created, and stored by the external_user_ids Djangoapp in the edx-platform. When this waffle is not enabled for a course - the default case - LTI 1.1 XBlock launches in that course will continue to send the user's anonymous_user_id as the user_id attribute of the launch, as before.

This provides an opt-in opportunity for courses to send a consistent, static, and opaque user identifier in an LTI 1.1 XBlock launch. This may be necessary for integration with LTI tools that require such an identifier.

Please be aware that toggling this flag in a running course carries the risk of breaking the LTI integrations in the course. This flag should also only be enabled for new courses in which no LTI attempts have been made.

build: update library version to 6.3.0 to release changes in pull #297

build: update library version to 6.2.0 to release changes in pull #297

Proctoring Service Implementation In-Browser Proctoring Launch

  * Adds an Lti1p3ProctoringLaunchData data class. It should be included as an attribute of the Lti1p3LaunchData
    data class to provide necessary proctoring data for a proctoring launch.
  * Adds an LtiProctoringConsumer class. This class is used to generate LTI proctoring launch requests and to decode
    and validate the JWT send back by the Tool with the LtiStartAssessment message.
  * Adds an lti_1p3_proctoring_enabled BooleanField to the LtiConfiguration model. This field controls whether
    proctoring is enabled for a particular LTI integration.
  * Modifies the launch_gate_endpoint to support LtiStartProctoring and LtiEndAssessment LTI launch messages.
  * Adds an start_proctoring_assessment_endpoint to support LtiStartAssessment messages from the Tool.
  * Adds an LTI_1P3_PROCTORING_ASSESSMENT_STARTED signal. This signal is emitted when the LtiStartAssessment message is
    sent from the Tool to inform users of the library that the LtiStartAssessment message has been received.

fix: remove general use of load_block_as_user