-
Bug
-
Resolution: Fixed
-
Major
-
3.11.10, 4.0.4
-
MOODLE_311_STABLE, MOODLE_400_STABLE
-
MOODLE_311_STABLE, MOODLE_400_STABLE
-
MDL-76113-master -
-
0
-
Team Hedgehog 4.1 pre 1.1, Team Hedgehog Sprint 1.1
This is like it says on the tin, this feature doesn't work for LTI 2.0 consumers.
Steps to reproduce
- Install two Moodle sites. Call one Platform and the other Tool
- In BOTH sites, disable Site admin > HTTP security > Blocked hosts to allow localhost-to-localhost connections to be made. Just clear the values and save it empty.
- Set up the tool site as follows:
- Enable the enrol_lti and auth_lti plugins
- Enable frame embedding via site admin
- Create a course on the tool site
- Create an assignment in the course called "Assignment 1"
- Publish the assignment by going to the course admin's "Published as LTI tools" link and selecting the assignment from the dropdown menu
- Note, for 400 and master, you should use the "Legacy LTI (1.1/2.0)" tab to publish the assignment over 1.1/2.0
- Copy the registration URL from the resulting table and store it somewhere for later.
- Now, sign in to the Platform site
- Go to Site admin > Plugins > Activities > External tool > Manage tools
- Paste the registration URL you copied earlier into the text field and click "Add Legacy LTI"
- Click to continue when prompted
- You should now see your tool in the manage tools listing
- Rename the tool "LTI 2.0 tool test"
- Create a course
- Enrol a student s1
- Click to add and activity, selecting "External tool"
- Select "LTI 2.0 tool test" from the list of preconfigured tools
- Name the activity instance "LTI 2.0 assignment test"
- Now, log out of the Platform site
- Log in to the platform site as the student s1
- Go to the course
- Click the "LTI 2.0 assignment test" link to launch the tool
- Submit something to the assignment
- Now, log out.
- Now, log in to the Platform site as the admin again
- Go to the course
- Launch the "LTI 2.0 assignment test" activity
- Grade the student submission, awarding them 88/100
- Now, via the CLI in the root of the Tool site, run:
php admin/cli/scheduled_task.php --execute="\enrol_lti\task\sync_grades"
- Observe the following output is present:
Failed - The grade '0.88' for the user 'XX' in the tool 'YY' for the course 'ZZ' failed to send.
Cause
What's happening is that the legacy sync_grades task fetches the enrol_lti_users records, which contain the wrong consumersecret when the tool has been used with LTI 2.0. This is then used to try to sign the payload, and of course this fails.
You can see what my database looks like here after a range of 1.0 (1.1) and 2.0 launches, and why the current query is problematic:
notice in particular the mismatch between ltiuserconsumersecret (the secret in the enrol_lti_users table) and lticonsumersecret (the secret in the enrol_lti_lti2_consumers table). This is only evident in LTI2.0 consumers.
Solutions
- One solution is left joining to the enrol_lti_lti2_consumer table, to check the version of the consumer; if the consumer is LTI 2.0, then we use the secret stored in the enrol_lti_lti2_consumer table, otherwise (if it's 1.1), the secret in the enrol_lti_users table is fine.
- Another solution may be to make sure the enrol_lti_user.consumerkey value is correct when creating users over LTI 2.0 launches (and make sure that it also updates correctly for existing users on subsequent launches). This unfortunately means we won't be able to sync grades until all affected users relaunch the tools - which makes it a less appealing solution. This would also involve data-fixing the affected enrol_lti_users records, as we won't catch those with the launch code change.
Perhaps a combination of the above would also be suitable.
Generally speaking, I like to leave the legacy code alone these days because those specifications have been deprecated for some time. In this instance, given fix 1 (as above) should be fairly trivial (not to mention LTI 2.0 specific and quite easy to test), I think this is worth fixing. There are probably a good few number of people out there who use the provider in legacy mode and don't realise by using the registration URL, they're using it as LTI 2.0 - meaning they're susceptible to this bug. This then ends in all sorts of grade sync failure reports on the forums, often with the mistaken assumption that the provider is set up using 1.1.
- blocks
-
MDL-76170 LTI legacy grade sync fails if member sync occurs before first user launch
- Closed
- caused a regression
-
MDL-76310 Enrol LTI upgrade of consumer secrets fails on Oracle
- Closed
- is a regression caused by
-
MDL-53832 Upgrade enrol_lti to support LTI v2.0
- Closed
- Testing discovered
-
MDL-76170 LTI legacy grade sync fails if member sync occurs before first user launch
- Closed