-
Bug
-
Resolution: Fixed
-
Major
-
3.11.10, 4.0.4
-
MOODLE_311_STABLE, MOODLE_400_STABLE
-
MOODLE_311_STABLE, MOODLE_400_STABLE
-
MDL-76170-master -
-
0
-
Team Hedgehog 4.1 pre 1.1, Team Hedgehog Sprint 1.1
Problem
Noticed this bug when patching MDL-76113 and it's pretty major.
To replicate, we essentially need to run a sync members job before the students launch into the tool the first time (this created bad entries which aren't fixed during subsequent launches, and ruins chances of a grade sync ever working):
- Install two Moodle sites. Call one Consumer and the other Provider
- 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 Provider site as follows:
- Enable the enrol_lti and auth_lti plugins
- Enable frame embedding via site admin
- On the provider site, create a course with two assignments and publish them both using legacy LTI
- Copy the cartridge URL + secret from the first published assignment (keep for later)
- Copy the registration URL from the second published assignment (keep for later)
- Now, on the consumer site go to site admin > manage tools
- Paste the cartridge URL and click "Add legacy LTI"
- Enter "testconsumer" for the consumer key when prompted, and paste in the secret
- Save, and you'll see an LTI 1.1 preconfigured tool is ready for use
- Name this tool "1.1 tool"
- Paste the registration URL and click "Add legacy LTI"
- This will have created an LTI 2.0 preconfigured tool now
- Name this tool "2.0 tool"
- Now create a course with 5 students s1..s5
- Add a new external tool instance and select the 1.1 tool
- Add a new external tool instance and select the 2.0 tool
- Launch the 1.1 tool as admin
- Launch the 2.0 tool as admin
- Now, in the provider web root, run legacy member sync:
php admin/cli/scheduled_task.php --execute="\enrol_lti\task\sync_members"
- Now, log in to the consumer site as the student s1
- Go to the course and launch the 1.1 tool
- Submit something to the assignment
- Now launch the 2.0 tool
- Submit something to the assignment
- Log out
- Log in to the consumer as the admin user and go to the course
- Launch the 1.1 tool and grade the user s1 50/100
- Launch the 2.0 tool and grade the user s1 60/100
- Now, in the tool site web root, run the legacy grade sync:
php admin/cli/scheduled_task.php --execute="\enrol_lti\task\sync_grades"
Expected: The grades 50/100 and 60/100 should be sent to the consumer
Actual: There's a message for both the 50/100 and the 60/100 stating "The grade....xx for the user yy in the tool zz for the course aa failed to send".
The member sync essentially creates empty enrol_lti_users records, which are never updated properly with the consumer secret, even on subsequent launched by the students. Were they to launch before the task ran, this wouldn't be the case and the secret would be present. The grade sync needs the secret to sign, and therefore the process will fail 100% of the time in such situations. As can be seen, this affects both 1.1 and 2.0 consumers. Given the member sync task is enabled by default, this bug is likely causing grade sync fails almost all the time in the legacy provider, rendering that feature essentially useless.
Solutions
The solution is to:
- Data fix the existing bad rows
- Make sure we do set the secret when missing during a launch. That way, when the members do eventually complete the activity, we'll have the consumer secret ready for use in the grade sync task, and everything will work as expected.
Again, normally I'd be reluctant to change these legacy services. However, as with the linked issue MDL-76113, this fix should be fairly trivial and will resolve an absolutely huge number of grade sync failures that are likely occurring in those sites still using the legacy provider (and would reduce the forum posts reporting such things too - always very difficult posts to address/resolve).
