refactor: replace deprecated runtime attributes

What's Changed

• Fix github url strings (org edx -> openedx) by @sarina in #280
• refactor: replace deprecated rebind_noauth_module_to_user, get_real_user, runtime.hostname, runtime.course_id [BD-13] by @tecoholic in #249

Full Changelog: 6.4.0...v7.0.0

adds support for sending external_user_id as user_id in LTI 1.1 XBlock launches

Adds support for sending an external_user_id in LTI 1.1 XBlock launches. When the
lti_consumer.enable_external_user_id_1p1_launches CourseWaffleFlag is enabled, the LTI 1.1 launch will send an
external_user_id as the user_id attribute of the launch. When the lti_consumer.enable_external_user_id_1p1_launches
CourseWaffleFlag is disabled, the LTI 1.1 launch will continue to send the anonymous_user_id. The external_user_id is
defined, created, and stored by the external_user_ids Djangoapp in edx-platform.

adds support for LTI 1.3 Proctoring Service specification 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 a 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.

6.1.0 greatly reduce block load to fix studio issues

6.0.0 broke studio functionality because it leaned more heavily on the xblock load which only worked in the LMS.
Fix by greatly limiting when we attempt a full xblock load and bind.

6.0.0 use config_id from launch data in API instead of block or config.id

BREAKING CHANGE:

Please note that additional breaking changes will be forthcoming in future versions of this library.

Modified Python API methods to use config_id (the UUID field) exclusively rather than config.id or block.
For the functions changed in 5.0.0 the config_id is available in the launch_data.
Other functions had config.id changed to config_id and block removed as an argument.
The new function config_id_for_block gets that config ID if all you have is a block.

Fix Failing LTI 1.3 Launch Due to Clickjacking Protection and Incorrect Authentication Response/Launch URL

X-Frame-Options DENY response header prevents LTI 1.3 launch

This commit fixes a bug caused by the X-Frame-Options response header. The X-Frame-Options response header indicates to the browser whether a site's content can be loaded within certain tags, including the <iframe> tag. This is a form of clickjacking protection.

In Django, this response header is set by the django.middleware.clickjacking.XFrameOptionsMiddleware middleware. In the edx-platform, by default, X-Frame-Options is set to DENY (see the X_FRAME_OPTIONS Django setting), which means that the response content returned by Django views cannot be loaded within certain tags. However, this behavior can be disabled by decorating views with the django.views.decorators.clickjacking.xframe_options_exempt view decorator.

This creates a problem for LTI 1.3 launches in the edx-platform. When an LTI component is loaded, the LtiConsumerXBlock is loaded via the lms.djangoapps.courseware.views.views.render_xblock_view view. This view is called in an <iframe> tag, but the view is decorated by the xfame_options_exempt decorator, which disables clickjacking protection and communicates to the browser that the content can be loaded in the <iframe> tag.

Once the third-party login request of the LTI 1.3 launch is completed, the LTI tool directs the browser to make a request to the launch_gate_endpoint. This endpoint returns a response, which is an auto-submitting form that makes a POST request - the LTI launch request - to the tool. This view has clickjacking enabled, so the browser blocks the requests, which prevents the launch from occurring.

This commit adds the xframe_options_exempt view decorator to the launch_gate_endpoint view.

Note that LTI 1.1 does not have this bug, because the LTI launch request is handled via the lti_launch_handler. The XBlock runtime handles requests to the LTI handlers via the openedx.core.djangoapps.xblock.rest_api.views.xblock_handler view, which is also decorated by the xframe_options_exempt view decorator.

LTI 1.3 launch URL should be redirect_uri provided by Tool in authentication request

This commit fixes a bug in the way we determine where to send the authentication response - the LTI 1.3 launch message - as part of an LTI 1.3 launch.

According to the 1EdTech Security Framework 1.0, during an LTI 1.3 launch, "the authentication response is sent to the redirect_uri." The redirect_uri is a query or form parameter provided by the tool when it directs the browser to make a request to the Platform's authentication endpoint. However, we currently send the authentication response to the preregistered launch URL - lti_1p3_launch_url in the LtiConsumerXBlock or the LtiConfiguration model. The difference is subtle, but it is important, because the specification indicates the Platform should respect the redirect_uri provided by the Tool, assuming it is a valid redirect_uri.

During the pregistration phase, "the Tool must provide one or multiple redirect URIs that are valid end points where the authorization response can be sent. The number of distinct redirect URIs to be supported by a platform is not specified." Currently, we do not support multiple redirect URIs, so the change is not immediately impactful. However, we should follow the specification and ensure that we return the authentication response to the correct URL.

Decouple XBlock Location Field from LTI 1.3 Views

BREAKING CHANGE:

Please note that additional breaking changes will be forthcoming in future versions of this library.

• Modified Python API methods to take Lti1p3LaunchData as a required argument

  • get_lti_1p3_launch_info
  • get_lti_1p3_launch_start_url
  • get_lti_1p3_content_url

• Added an Lti1p3LaunchData data class

• Added caching for Lti1p3LaunchData to limit data sent in request query or form parameters

• Replaced references to LtiConsumerXBlock.location with Lti1p3LaunchData.config_id

• Removed definition of key LTI 1.3 claims from the launch_gate_endpoint and instantiated Lti1p3LaunchData from within the LtiConsumerXBlock instead

• Added a required launch_data_key request query parameter to the deep_linking_content_endpoint and refactored associated templates and template tags to pass this parameter in the request to the view

• Changed the access token URL and Keyset URL to use the LtiConfiguration.config_id in the URL instead of the LtiConfiguration.location

Handle LtiError Error During LTI 1.1 Launch for Unauthenticated User

In the LTI 1.1 launch handler, we set the user context. We do this by calling to the LMS's DjangoXBlockUserService to get information about the user. Sometimes, the user is unauthenticated. Sometimes, this is because the user is a web crawler. Other times, the user is a real user, but we do not know why the user is unauthenticated. We have some theories, but we have been unable to confirm them. Regardless, we should not surface a 500 error to the user.

This release adds handling for the LtiError that is raised when a user is unauthenticated during an LTI 1.1 launch. It catches the LtiError and renders an error page. The error page that was used for LTI 1.3 launches was modified to remove the reference to the version of LTI used by the XBlock; these details are unnecessary for a learner, and removing them allows us to reuse a single template for both LTI versions. This template is now used for LTI 1.1 errors as well.

This release also reverts a previous commit that added additional logging to help investigate the error.

Decouple LTI 1.3 views from XBlock

Moving XBlock handlers to Django views to bring us a step closer to LTI 1.3 launches independent from the context of a block.

See #254 for more details.

Fix Missing Exception Details in Logs

The error handler in LtiConsumerXBlock.lti_1p3_launch_callback logs a warning when a select set of exceptions are handled. That log does not contain useful information about the nature of the exception, because the exceptions were not being instantiated with error messages. The try...catch is a large block that contains code that can raise a multitude of errors, so these changes will enable better debugging.

This commit:

• adds helpful messages to the raised exceptions.
• adds the exc_info=True argument to include the stack trace of the handled exception.
• adds ValueError and TypeError to the list of handled exceptions, because the code can raise exceptions of these types.