instructure / canvas-lms

The open LMS by Instructure, Inc.
https://github.com/instructure/canvas-lms/wiki
GNU Affero General Public License v3.0
5.57k stars 2.47k forks source link

LTI 1.3's Names and Role Provisioning Service throws an error on url matching migration from LTI 1.1 #2289

Open JonathanGawrych opened 10 months ago

JonathanGawrych commented 10 months ago

Summary:

We would like to use the Name and Role Provisioning Service in our LTI Tool. We further want to use the Resource Link Membership Service by passing the resource_link_id as a rlid query parameter to retrieve extra information. This works if we create a brand new LTI 1.3 tool, or edit an assignment from an LTI 1.1 tool and change it to the LTI 1.3 tool, but it does not work if the LTI 1.1 tool is migrated to a LTI 1.3 using url matching. Instead you get the following error:

Requested ResourceLink bound to unexpected external tool

Looking in the logs gives a more detailed error:

ResourceLink (rlid: 0ab6a979-dba9-4ca0-9075-7218a1c061ff) needs binding to external tool 2 but found 1

Steps to reproduce:

  1. Go to Admin -> pick your account -> settings -> Apps -> View App Configurations -> +App -> Fill out the LTI 1.1 information, making note of the Launch Url
  2. Create a course.
  3. Create an assignment. Use submission type "External Tool" finding and selecting the tool above.
  4. Go back to Admin -> pick your account -> settings -> developer tools -> +Developer Key -> +LTI key -> Fill out the LTI 1.3 information. Make sure to put the LTI 1.1 Launch Url into the Target Link URI field.
  5. Launch the assignment. Note that it is doing LTI 1.3 without changing the external tool
  6. Attempt to call the names and roles provisioning service with the passed in rlid

Expected behavior:

We would retrieve the membership list

Actual behavior:

We get an error about external tool binding

Additional notes:

This error is thrown in memberships_provider.rb validate_tool

marcospri commented 2 weeks ago

We are also affected by this bug, following the same reproduction steps.

We tried using both the resource_link -> id and the claim/lti1p1/resource_link_id versions, just in case that might help. Unfortunately, it didn't.