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

[SomDaveYoung]

Hi @xcesaralejandro @DavidBrooks @joelfranke 

Has anyone come up with an answer to this issue? @xcesaralejandro Did you ever hear back from Instructure when they escalated the issue? I'm seeing the exact same thing. The exact same `resource_link_id` regardless of where the request is initiated from.

Our LTI 1.1 implementation receives a unique identifier for each location where the resource link was initiated (course navigation, module, etc) but with LTI 1.3 the resource_link_id is always the same. 😞

Struggling to find a unique bit of info in the launch JWT that will let me know what content to present. 

[xcesaralejandro]

We escalated the problem, they agreed to refer it to the technical team and we never received an answer. Some time ago they fixed it arbitrarily without warning, that corrupted our tools because all the data was tied to the old identifiers, but on the other hand, we were happy that now we get a unique identifier for each resource in the course.

I must criticize Canvas, because they didn't even notify or document this change, they preferred to do it in silence and screw whoever has to screw it (We screwed ourselves one morning discovering the problem).

Until then we haven't had that problem of the same identifier for LTI 1.3 as course resources anymore, in fact I just tested it right now and it works perfectly.

On the other hand, what I still can't achieve is being able to link LTI advantage with canvas, with moodle everything works fine for me, but canvas returns a 401, despite the fact that I have created comments in forums and searched for information, I only find people who They have the same problem but no solutions.
If you require LTI 1.3 you should rethink if it is a better option over LTI 1.0 - 1.1.
Since in our institution we only use canvas, we are using LTI 1.3 as a launcher for basic applications that do not require LTI Advantage, for the rest of the things we combine with the canvas API (graphql / rest) and with that we have a larger universe of possibilities regarding LTI Advantage.

In my institution there are few developers who work with LTI, not to say that I am the only one. I had to suffer a lot figuring out the protocol and struggling to figure out if the problem was me or canvas.

Finally I ended up creating a humble package for Laravel, I share it with you because it could be useful to you, I am aware that it lacks documentation (due to lack of time), but lastly to do reverse engineering, if you have worked with Laravel it should not be so complex to understand the code.

LTI 1.3 + LTI Deep Linking (It has support for installation to global context and by course)
https://github.com/xcesaralejandro/lti1p3

Canvas Oauth, (This package allows you to manage the canvas api keys to consume your services)
https://github.com/xcesaralejandro/canvasoauth

These two packages can live together but you have to override several methods and without documentation it can take some time, I hope to consolidate it into a new package but not before freeing myself from some projects to have time.


Important
Another recent issue you may identify with LTI 1.3 is that canvas is returning for some courses another obfuscated LTI identifier for the same user, that's been a pain in the butt. I finally solved it with variable substitution, passing in my lti the canvas_id of the user.

[SamuelBellows]

I am seeing the same thing. Matching context and resoruce_link ids, and the deyployment_id is coupled as well.

"https://purl.imsglobal.org/spec/lti/claim/deployment_id": "23:e2bd47c3dd4323f0a99144bb15b897e61e8e39f3"

"https://purl.imsglobal.org/spec/lti/claim/context": {

    "id": "e2bd47c3dd4323f0a99144bb15b897e61e8e39f3",...

"https://purl.imsglobal.org/spec/lti/claim/resource_link": {

    "id": "e2bd47c3dd4323f0a99144bb15b897e61e8e39f3",...

Any word from the Canvas people?

[xcesaralejandro]

This problem was solved by canvas many months ago, it was not documented and it caused us problems at the time. Since then we have had no problems with duplicate keys.

Canvas recently announced the modification of the OIDC authentication points, (https://canvas.instructure.com/api/lti/authorize_redirect changes to https://sso.canvaslms.com/api/lti/authorize_redirect), although It is not a disruptive change, it implies that they are doing things and eventually there could be temporary failures.

On the other hand, when I worked with LTI DeepLinking I noticed that there were similar locations but with totally different behaviors (in the locations section for the lti, when you define where you are going to add it). After reading the forums, I understood that some locations were intended for older versions of LTI and had strange behavior with LTI 1.3. I have looked superficially now and it seems that they have been removed.

Do you still have the problem?