LTI 1.3 - Tool and ressources
LTI 1.3 - Tool and ressources
Submitted by b.xavier on Thu, 04-Jul-2019 08:59.
Hi there,
I am currently implementing the LTI 1.3 tool but some things seems obscur and I would like a bit of help.
When receiving a LtiResourceLinkRequest, how am i suppose to know what to launch.
Can i do something like "lti/{tool_id}/launch/{resource_id}" ?
Seems legit to me. But in moodle when configuring tool you must have to set this url in a list. So for each new activity you must add it, and that does not seem a cool thing to maintain !
So maybe I have to make a link between the context and my resource in my project in any form ? That could be a simple column in database ?
Or maybe a tool is suppose to be used in a small context. So no link have to be made and the tool itself is the resource ?
Could I have any light on this ?
Hi,
Hi,
I think the way to look at it is that as a Tool you control your own links. You always create the links to the resources or capabilities exposed by your tool, and then you make those links available to the Platform. There are several ways you can do this, you can implement Deep Linking and dynaically create LTI link resources which are returned to the Platform and added to the 'current context/course', or you can pre-create LTI link resources and distribute then to the Platoform as part of an IMS Common Cartridge (see http://www.imsglobal.org/spec/lti/v1p3/#representing-lti-links-in-an-ims-common-cartridge ) etc.
One common approach is to add one or more custom params to the LTI links you create which the Platform will include in the LTI launch, these can be whatever you want (subject to length/encoding restrictions), you could use a param who's value was a URL, or a resourceId of some kind which your Tool will understand. The advantage here is that if you use e.g. a resource identifier which is a simple, fixed format (e.g. a uuid) it can be easier to validate and secure (a full url would typically require additional security validations to prevent the use of the Tool as an open redirector, avoid path traversal attacks etc. and there have been a lot of successful attacks on regexp validation of urls in OpenId Connect implementations leading to a security guidance from the OpenId group to do only full string comparison validation of URLs used.)
There is also a concept of a target_link_uri which can be passed in the OpenId Connect 3rd party login initiation flow and which will then be passed to the Tool as a claim (
https://purl.imsglobal.org/spec/lti/claim/target_link_uri) and can be provided to the Tool as the launch_url param in an LTI resource in a Common Cartridge etc. so you could use lti/{tool_id}/launch/{resource_id} here, but it may be simpler and easier to secure to pass resource_id as a custom param, and use client_id as tool_id (or if you do need multiple tools with the same security contract then add a second custom param for tool_id).All the best,
Padraig