-
Bug
-
Resolution: Fixed
-
Major
-
4.0
-
MOODLE_400_STABLE
-
MOODLE_400_STABLE
-
MDL-74221-master -
-
3
-
QA time, QA time 2
The problem
There's an optional client_id param that can be sent to the initiate_login_uri (https://www.imsglobal.org/spec/lti/v1p3/#client_id-login-parameter). Moodle needs this, along with issuer, to identify a local registration for the issuer/client pair (identifying the platform and the client on said platform), and continue with the next stage of the launch.
If this param is omitted in the call to our login endpoint (technically possible according to the spec - see link above), we're unable to find the registration and cannot proceed to the next stage of the launch (annoyingly, where client_id IS mandatory as part of the JWT data).
I believe the inclusion of client_id as an optional login param was a late addition to the spec, but either way, it's optional nature means we need to address this so that we can still accept launches in such cases.
Note also: The problem here only presents itself in the test suite so far, but is technically possible in a real platform use case too (though I will note that at least Canvas and Moodle don't exhibit this problem).
The solution
The widely adopted solution is to accept a unique 'id' param in either the initiate_login_uri, or in the target_link_uri, allowing Moodle to use this param instead of the missing client id. This of course requires that Moodle is aware of this id BEFORE the creation and use of the registration URLs - not currently the case, because all URLs are generic.
So, the process should work as follows (assuming the param is sent to the initiate_login_uri):
- Admins will now need to create a incomplete/stub registration, before being able to view and copy the endpoint URLs. This acts like a draft.
- When creating the stub/incomplete registration, Moodle will generate and store a unique id for the registration - for later use in the (now dedicated) login uri.
- The admin will copy the endpoint URLs as they did before, but will now see '?id=xxxx' in the initiate login URI.
- Registration continues as normal, with the admin recording the various URLs in Moodle as part of completing the registration
- When launching, login.php (the initiate login endpoint) will now see 'id' as a param there. At this time, depending on whether the optional client_id param has been sent or not, Moodle can identify the registration by either:
- {iss, client_id}
- if client_id has been sent
- {iss, id}
- in cases where the optional client_id is omitted
- {iss, client_id}
- Dynamic registration will also need to be made aware of the new login param, when returning it's configuration to the platform.