Skip to content
Snippets Groups Projects
  1. May 15, 2023
  2. May 08, 2023
  3. May 05, 2023
    • Isaac Lee's avatar
      Ilee2u/acs endpoint (#369) · 61fb2782
      Isaac Lee authored
      
      * feat: support assessment control claims
      
      * test: unit tests
      
      * feat: ACS scope handling
      
      * fix: correct acs url
      
      * fix: removed drafted signal code
      
      * test: added permissions test
      
      * docs: added note on individual file testing
      
      * docs: moved unit testing notes to readme
      
      * chore: version bump
      
      * temp: broken code to filter ACS scope perms
      
      - Tried to create a filter in the access_token end point to only add the ACS scope only when proctoring is enabled
      - This seems to hard to do without causing a circular dependency
      
      * fix: removed filter for ACS access token
      
      ---------
      
      Co-authored-by: default avatarZach Hancock <zhancock@edx.org>
      61fb2782
  4. May 03, 2023
  5. May 02, 2023
  6. Apr 28, 2023
  7. Apr 25, 2023
  8. Apr 18, 2023
  9. Apr 12, 2023
  10. Apr 11, 2023
  11. Mar 06, 2023
    • Geoff's avatar
      299 validate redirect uris (#302) · 6c9c0ef3
      Geoff authored
      * Adds lti_1p3_redirect_uris to XBlock
      * Adds lti_1p3_redirect_uris to LTIConfiguration model
      * Asserts redirect_uri from preflight response in valid redirect uris during preflight validation
      * To minimize disruption for previous versions, uses current launch url and deep linking url as default registered redirect_uris if redirect_uris is not explicitly set
      6c9c0ef3
  12. Feb 03, 2023
    • michaelroytman's avatar
      fix: inappropriate instructions for inline PII sharing consent dialog · dcf80007
      michaelroytman authored
      This commit fixes inappropriate instructions displayed when collecting PII sharing consent before an inline LTI launch. Previously, the instructions said, "Click OK to have your [username (and) e-mail address] sent to a 3rd party application. Click Cancel to return to this page without sending your information." The latter sentence does not make sense in the context of an inline launch, because there is no cancel button. This commit modifies the inline PII sharing consent dialog to say, "Click OK to have your [username (and) e-mail address] sent to a 3rd party application.""
      dcf80007
  13. Jan 31, 2023
  14. Jan 30, 2023
  15. Jan 24, 2023
    • michaelroytman's avatar
      fix: bug in rending buttons and message in PII sharing consent dialog · d95de6e8
      michaelroytman authored
      This commit fixes a bug in the PII sharing consent dialog.
      
      The bug resulted in bizarre behavior when there were more than one LTI component in a unit. For example, if there were two LTI inline launches in a unit, two "OK" button would appear in a single component, instead of in their respective components. Another example is that clicking the "View resource in a [modal|new] window" buttons under two LTI components resulted in the "OK" and "Cancel" buttons as well as the PII sharing prompt appearing in a single component, instead of in their respective components.
      
      This is because the dialog-container div that is dynamically created in the Javascript was not scoped to the LTI component, so there was a div with a id of "dialog-container" for each component configured to share PII. When dynamically inserting and removing buttons and the PII sharing prompt, the Javascript would simply find the first div with the dialog-container ID and operate on it, instead of the div appropriate to the component the user is interacting with.
      d95de6e8
    • Giovanni Cimolin da Silva's avatar
      Merge pull request from GHSA-7j9p-67mm-5g87 · 252f94bd
      Giovanni Cimolin da Silva authored
      
      * fix: Tool can only push grade to value in config
      
      Before this commit, LTI tools were able to push grades to any block
      simply by modifying or creating a new line item with a `resource_link_id` containing a valid block.
      
      This commit closes that loophole and resolves
      security advisory GHSA-7j9p-67mm-5g87.
      
      * chore: create release version
      
      Co-authored-by: default avatarZach Hancock <zhancock@edx.org>
      252f94bd
  16. Jan 10, 2023
  17. Dec 15, 2022
  18. Dec 09, 2022
    • Zachary Hancock's avatar
      feat: adds setting to prevent nrps pii (#315) · 3f2bab5e
      Zachary Hancock authored
      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
      3f2bab5e
  19. Dec 02, 2022
  20. Nov 29, 2022
  21. Nov 21, 2022
  22. Nov 18, 2022
    • michaelroytman's avatar
      feat: add course flag to send external_user_id as user_id in LTI 1.1 XBlock launches · cff7744e
      michaelroytman authored
      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.
      cff7744e
  23. Nov 16, 2022
    • michaelroytman's avatar
    • michaelroytman's avatar
      feat: adds support for LTI 1.3 Proctoring Service specification in-browser proctoring launch. · 6288b2a0
      michaelroytman authored
        * 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.
      6288b2a0
  24. Nov 07, 2022
    • Andy Shultz's avatar
      fix: remove general use of load_block_as_user · 5f964f1d
      Andy Shultz authored
      For the config model we do not need to go as far as binding the block
      to the user and already get enough data out of the modulestore to
      satisfy the storage on the xblock case. Add a new function to get that
      much xblock only.
      
      For the limited cases where we are using the block more directly as a
      block we maintain the old function.
      
      Also includes a fix to test_views that was closing the wrong level
      mock and leaving an open patch into other tests.
      5f964f1d
  25. Oct 20, 2022
    • Andy Shultz's avatar
      feat: update lti API to pick config via launch data · a52eef76
      Andy Shultz authored
      Note that this uses config_id (the UUID) not config.id (the int)
      
      This required a way to get config_id if we only have the block.
      
      And it means that we are more likely to go through load_block_as_user
      because we have not created the config off the block even when calling
      from the block (since the block has to go through that config ID).
      
      A lot of tests had to be updated to have more complete configuration
      setup because config_id is now load bearing.
      a52eef76
  26. Oct 17, 2022
  27. Oct 13, 2022
    • michaelroytman's avatar
      feat!: decouple LTI 1.3 launch from LtiConsumerXBlock · f7b9d401
      michaelroytman authored
      Purpose
      -------
      
      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
      f7b9d401
  28. Sep 13, 2022
Loading