LTI 1.3 Same resource link for all course item instances

[xcesaralejandro]

I am developing an LTI 1.3, however for all my resource instances I get the same resourceLink, which has the context ID as an identifier. Why does this happen?

Defining the scope for my lti:

I am currently linking the LTI directly with the url:

After that, my lti resource is already part of my course, everything seems to be going well so far.

}

When entering the resource, I don't get information from the resource, like the name it was assigned in canvas, the id of my resourceLink is the same id of the context.

The real problem occurs now, if within my course I repeat these steps and add more resources from the same LTI, they will all have the same resourceLink, therefore, within my LTI I cannot differentiate the resource (Since all resourceLink IDs are the same) and therefore all the data within the LTI will be crossed between module item instances.

[joelfranke]

Commenting to follow.

Have seen something similar in JWTs issued at launch where the value of "https://purl.imsglobal.org/spec/lti/claim/resource_link" is identical as "https://purl.imsglobal.org/spec/lti/claim/context". Based on the spec, I would think this is supposed to be unique (and distinct) relative to the course context.

[DavidBrooks]

I see exactly the same situation. I have a demo app using LTI 1.3, and for link_selection placements that are configured for Deep Linking, this always happens. I then assumed it might be related to Deep Linking, so I reconfigured link_selection to use resource-link launch, and the same situation occurred.

This seems to be new to LTI 1.3. We have two other LTI apps, both on LTI 1.1. The first uses resource_link launches (not Content Item or Deep Link), and it always gets distinct resource_link IDs. The second uses Content Item (precursor to Deep Link), and it also always gets distinct resource_link IDs.

Does anyone know whether this is this a known bug in Canvas?

[xcesaralejandro]

@DavidBrooks 

After this publication, I got in touch with the person in charge of canvas in my institution, who can talk and manage things with instructure, we sent emails and the company was told, they left to escalate the problem to the technical area but to day today I am not getting an answer to know if it is a canvas problem or my implementation.

When we developed an lti in the institution, luckily we needed only one instance per course, but it does not make sense to return the same resource link for all instances, personally I think it is an error of canvas.

And speaking of errors, when I tried to implement "LTI Adventage" to get the members I could never get the final token, although I remember I always got a 401 error from http (I can't remember the error code exactly) for part of canvas even though the previous code that was passed to oauth was generated successfully.

LTI 1.3 is different than lti 1.1 implementation on canvas from what I read, so it will probably work on one and not on the other.

When I read the IMS Global specification, the specification never spoke of the same identifier for all instances, which again leads me to an error on the part of canvas, but it could be tested in other LMS, perhaps in moodle, just to make sure that this is actually a canvas problem.

It is all I know and what I suffered with lti 1.3, I hope it will be useful to you