Changes: https://github.com/openedx/codejail/compare/3.1.3...3.3.0
The only notable change here is that codejail's setup.py
has been fixed so that it includes all necessary files
in its distribution. This addresses an issue that happened
last time we tried to update codejail's pin in edx-platform
to be a wheel instead of editable (development) mode:
the proxy_main.py and memory_stress.py files were missing.
We update github.in to use the proper git-based depencency
format specified in the file comment. This format installs
a package as a pre-built wheel:
git+https://github.com/...
instead of a development-mode editable requirement:
-e https://github.com/...
Installing packages in editable mode increases the amount of time
it takes to install edx-platform dependencies, increases the
resulting virtual environment's size, and installs packages in a
way that has several subtle differences compared to the way
wheels are installed:
https://setuptools.pypa.io/en/latest/userguide/development_mode.html#limitations
NOTE: This commit also upgrades django-require its latest version.
(changelog:
https://github.com/openedx/django-require/compare/0c54ad...f4f01e)
The difference between the current version and the latest version
is entirely clerical; there are no code changes.
NOTE: This commit also upgrades blockstore from 1.2.4 to 1.2.5
(changelog:
https://github.com/openedx/blockstore/compare/1.2.4...1.2.5).
The only outward-facing difference between those two releases
is that 1.2.4 can only be installed in editable mode, whereas
1.2.5 has its setup.py fixed so that it can be installed as
a pre-build wheel.
They give the impression that, for example,
third-party XBlocks belong in github.in.
In reality, GitHub-hosted requirements should be avoided
in all circumstances. Third-party XBlocks are best
added to base.in as a PyPI-hosted dependency.
Furthermore, the existing section headers are not
even being followed.
This commit upgrades the version of the lti-consumer-xblock library from version 5.0.0 to version 5.0.1. This new version contains two fixes to the LTI 1.3 launch Flow. These fixes should enable LTI 1.3 launches, which are currently broken.
Please see the CHANGELOG entry for this version for a full description of the fixes: https://github.com/openedx/xblock-lti-consumer/blob/master/CHANGELOG.rst#501---2022-10-17. The commit messages are included below for convenience.
fix: 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.
fix: 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.
This commit upgrades the version of the lti-consumer-xblock library from version 4.5.0 to version 5.0.0. This new version contains breaking changes to the public Python API published by the library, but it mainly contains code refactors that decouple the LtiConsumerXBlock.location field from the basic LTI 1.3 launches.
LTI 1.3 launches should continue to work unaltered.
The only course staff or instructor facing changes are described below. The access token and keyset URLs displayed in Studio have changed in format.
The old format was:
Access Token URL: https://courses.edx.org/api/lti_consumer/v1/token/block-v1:edX+999+2022Q3+type@lti_consumer+block@714c10a5e4df452da9d058788acb56be
Keyset URL: https://courses.edx.org/api/lti_consumer/v1/public_keysets/block-v1:edX+999+2022Q3+type@lti_consumer+block@714c10a5e4df452da9d058788acb56be
The new format is:
Access Token URL: https://courses.edx.org/api/lti_consumer/v1/token/c3f6af60-dbf2-4f85-8974-4ff870068d43
Keyset URL: https://courses.edx.org/api/lti_consumer/v1/public_keysets/c3f6af60-dbf2-4f85-8974-4ff870068d43
The difference is in the slug at the end of the URL. In the old format, the slug was the UsageKey of the XBlock associated with the LTI integration. In the new format, the slug is the config_id of the LtiConfiguration associated with the LTI integration. This is an iterative step toward decoupling the access_token_endpoint and the public_keyset_endpoint views from the XBlock location field. The XBlock location field appears as the usage_key parameter to both views. We cannot simply remove the usage_key parameter from the views, because existing LTI 1.3 integrations may have been created using the old format, and we need to maintain backwards compatibility. This change, however, prevents new integrations from being created that are coupled to the XBlock. In the future, we may address integrations that use the old format to fully decouple the XBlock from the views.
