-
michaelroytman authoredPurpose ------- The purpose of these changes is to decouple the LTI 1.3 launch from the LtiConsumerXBlock. It is in accordance with the ADR "0007 Decouple LTI 1.3 Launch from XBlock and edX Platform", which is currently under review. The pull request for the ADR is here: https://github.com/openedx/xblock-lti-consumer/pull/281. The general premise of these changes is to shift the responsibility of defining key launch claims to users of the library. Such claims include user ID, user role, resource link ID, etc. Prior to this change, this context was defined directly in the launch view by referencing XBlock fields and functions, thereby tying the LTI 1.3 launch to the XBlock. By shifting the responsibility out of the view, we will be able to genericize the launch and make it functional in more contexts than just the XBlock and the XBlock runtime. In short, the key launch claims are encoded in an instance of a data class Lti1p3LaunchData. Users of the library will instantiate this class with necessary launch data to it and pass the instance to various methods of the Python API to communicate the data to the library. Please see the aforementioned ADR for more details about this decoupling strategy. Note that the majority of these changes affect only the basic LTI 1.3 launch. There have largely been no changes to LTI 1.3 Advantage Services. The one exception is the Deep Linking content launch endpoint. This is because this launch is implemented in the basic LTI 1.3 launch, and it was necessary to make the same changes to the deep linking content launch to ensure that it works properly. Otherwise, LTI 1.3 Advantage Services are out of scope of these changes. Change Summary for Developers ----------------------------- Below is a summary of changes contained in this pull request. * added an Lti1p3LaunchData data class * added caching for Lti1p3LaunchData to limit data sent in request query or form parameters * BREAKING CHANGE: 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 * 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 Change Summary for Course Staff and Instructors ----------------------------------------------- The only changes relevant for course staff and instructors is that 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. Testing ------- Unit tests were added for all changes. In addition, manual testing was performed using the instructions in the documents listed below. * https://github.com/openedx/xblock-lti-consumer#lti-13 * https://openedx.atlassian.net/wiki/spaces/COMM/pages/1858601008/How+to+run+the+LTI+Validation+test Resources --------- JIRA: MST-1603: https://2u-internal.atlassian.net/browse/MST-1603 BREAKING CHANGE
michaelroytman authoredPurpose ------- The purpose of these changes is to decouple the LTI 1.3 launch from the LtiConsumerXBlock. It is in accordance with the ADR "0007 Decouple LTI 1.3 Launch from XBlock and edX Platform", which is currently under review. The pull request for the ADR is here: https://github.com/openedx/xblock-lti-consumer/pull/281. The general premise of these changes is to shift the responsibility of defining key launch claims to users of the library. Such claims include user ID, user role, resource link ID, etc. Prior to this change, this context was defined directly in the launch view by referencing XBlock fields and functions, thereby tying the LTI 1.3 launch to the XBlock. By shifting the responsibility out of the view, we will be able to genericize the launch and make it functional in more contexts than just the XBlock and the XBlock runtime. In short, the key launch claims are encoded in an instance of a data class Lti1p3LaunchData. Users of the library will instantiate this class with necessary launch data to it and pass the instance to various methods of the Python API to communicate the data to the library. Please see the aforementioned ADR for more details about this decoupling strategy. Note that the majority of these changes affect only the basic LTI 1.3 launch. There have largely been no changes to LTI 1.3 Advantage Services. The one exception is the Deep Linking content launch endpoint. This is because this launch is implemented in the basic LTI 1.3 launch, and it was necessary to make the same changes to the deep linking content launch to ensure that it works properly. Otherwise, LTI 1.3 Advantage Services are out of scope of these changes. Change Summary for Developers ----------------------------- Below is a summary of changes contained in this pull request. * added an Lti1p3LaunchData data class * added caching for Lti1p3LaunchData to limit data sent in request query or form parameters * BREAKING CHANGE: 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 * 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 Change Summary for Course Staff and Instructors ----------------------------------------------- The only changes relevant for course staff and instructors is that 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. Testing ------- Unit tests were added for all changes. In addition, manual testing was performed using the instructions in the documents listed below. * https://github.com/openedx/xblock-lti-consumer#lti-13 * https://openedx.atlassian.net/wiki/spaces/COMM/pages/1858601008/How+to+run+the+LTI+Validation+test Resources --------- JIRA: MST-1603: https://2u-internal.atlassian.net/browse/MST-1603 BREAKING CHANGE
dev.txt 4.07 KiB
#
# This file is autogenerated by pip-compile with python 3.8
# To update, run:
#
# make upgrade
#
appdirs==1.4.4
# via
# -r requirements/base.txt
# fs
asgiref==3.5.2
# via
# -r requirements/base.txt
# django
attrs==22.1.0
# via -r requirements/base.txt
bleach==5.0.1
# via -r requirements/base.txt
certifi==2022.9.24
# via
# -r requirements/base.txt
# requests
cffi==1.15.1
# via
# -r requirements/base.txt
# pynacl
charset-normalizer==2.1.1
# via
# -r requirements/base.txt
# requests
click==8.1.3
# via
# -r requirements/base.txt
# edx-django-utils
django==3.2.15
# via
# -r requirements/base.txt
# django-config-models
# django-crum
# django-filter
# djangorestframework
# edx-django-utils
# edx-i18n-tools
# jsonfield
# openedx-filters
django-config-models==2.3.0
# via -r requirements/base.txt
django-crum==0.7.9
# via
# -r requirements/base.txt
# edx-django-utils
django-filter==22.1
# via -r requirements/base.txt
django-waffle==3.0.0
# via
# -r requirements/base.txt
# edx-django-utils
djangorestframework==3.14.0
# via
# -r requirements/base.txt
# django-config-models
edx-django-utils==5.1.0
# via
# -r requirements/base.txt
# django-config-models
edx-i18n-tools==0.9.1
# via -r requirements/dev.in
edx-opaque-keys[django]==2.3.0
# via -r requirements/base.txt
fs==2.4.16 # via
# -r requirements/base.txt
# xblock
future==0.18.2
# via
# -r requirements/base.txt
# pyjwkest
idna==3.4
# via
# -r requirements/base.txt
# requests
jsonfield==3.1.0
# via -r requirements/base.txt
lazy==1.5
# via -r requirements/base.txt
lxml==4.9.1
# via
# -r requirements/base.txt
# xblock
mako==1.2.3
# via
# -r requirements/base.txt
# xblock-utils
markupsafe==2.1.1
# via
# -r requirements/base.txt
# mako
# xblock
newrelic==8.2.0.181
# via
# -r requirements/base.txt
# edx-django-utils
oauthlib==3.2.1
# via -r requirements/base.txt
openedx-filters==0.8.0
# via -r requirements/base.txt
path==16.5.0
# via edx-i18n-tools
pbr==5.10.0
# via
# -r requirements/base.txt
# stevedore
polib==1.1.1
# via edx-i18n-tools
psutil==5.9.2
# via
# -r requirements/base.txt
# edx-django-utils
pycparser==2.21
# via
# -r requirements/base.txt
# cffi
pycryptodomex==3.15.0
# via
# -r requirements/base.txt
# pyjwkest
pyjwkest==1.4.2
# via -r requirements/base.txt
pymongo==3.12.3
# via
# -r requirements/base.txt
# edx-opaque-keys
pynacl==1.5.0
# via
# -r requirements/base.txt
# edx-django-utils
python-dateutil==2.8.2
# via
# -r requirements/base.txt
# xblockpytz==2022.4
# via
# -r requirements/base.txt
# django
# djangorestframework
# xblock
pyyaml==6.0
# via
# -r requirements/base.txt
# edx-i18n-tools
# xblock
requests==2.28.1
# via
# -r requirements/base.txt
# pyjwkest
simplejson==3.17.6
# via
# -r requirements/base.txt
# xblock-utils
six==1.16.0
# via
# -r requirements/base.txt
# bleach
# fs
# pyjwkest
# python-dateutil
sqlparse==0.4.3
# via
# -r requirements/base.txt
# django
stevedore==4.0.0
# via
# -r requirements/base.txt
# edx-django-utils
# edx-opaque-keys
urllib3==1.26.12
# via
# -r requirements/base.txt
# requests
web-fragments==2.0.0
# via
# -r requirements/base.txt
# xblock
# xblock-utils
webencodings==0.5.1
# via
# -r requirements/base.txt
# bleach
webob==1.8.7
# via
# -r requirements/base.txt
# xblock
xblock==1.6.1
# via
# -r requirements/base.txt
# xblock-utils
xblock-utils==3.0.0
# via -r requirements/base.txt
# The following packages are considered to be unsafe in a requirements file:
# setuptools