How to update a dynamically registered LTI tool configuration

[svickers2]

I have an LTI developer key which was configured using a dynamic registration URL.  I cannot find a way of updating this configuration via the UI, and the documentation for the API states that "updating the base tool configuration of a registration that is associated with a Dynamic Registration will return a 422".

So my question is, when the tool moves to a new domain, how can I update Canvas so that existing links send their messages to the new location?

If I cannot update the URLs associated with the developer key, is it possible to create a new one and migrate all links associated with the old one to the new one?  Or some other solution such that existing links will continue to work?

Thanks.

[chriscas]

Hi @svickers2,

I guess i'll start off by asking what kind of placements your tool uses.  If it's just a course navigation link or something similar, updating may be pretty easy.  If you're using an assignment or editor placement with deep linking, things are probably going to get a lot more complicated.  Updating the tool config itself should be fairly straightforward in the GUI, but all of the individual uses of the tool for things like assignments or editor links are going to need to be updated as well, which is likely doable through the API, but it will likely take quite a bit of scripting to find and replace everything.

If you can post back here with some more info, there may be someone who can give more specific info or help.

-Chris

[svickers2]

Thanks for the response @chriscas.  My current example only involves a link selection placement, and is not using deep linking.  If you have found a way of making the change using the GUI then I'd be very interested to learn of it.  So far all I have been able to do is update the target link URI, but not the initiate login URL, redirect URIs, JWKS URL, etc.

[chriscas]

Hi @svickers2,

I'm assuming you created a dynamic LTI 1.3 developer key, right?  I don't have any dynamically registered tools right now, but my understanding is that once the tool is created, you can edit the developer key just like any other, modifying placements, URLs, etc.  Could you perhaps hare a screenshot of the screen in the GUI you see for editing?  That may help clarify things for me.

-Chris

[svickers2]

Thanks for the quick response.  When a developer key has been created using dynamic registration, the "Edit key" option on the Developer Keys page only offers the ability to make changes to the Permissions, User data shared with this tool, and Placements.  This is unlike the edit key option for a manually configured developer key which displays the original configure page.

[svickers2]

I received this response from Instructure Support:

"There is currently no possibility of updating the dynamically created dev key once it's configured."

So, as dev keys created in other ways can be updated, it seems like dynamic registration is best avoided.  I have not yet been able to discover why dynamically registered dev keys are being treated differently from others.

[chriscas]

Hi @svickers2,

Thanks for the update.  This is interesting, and probably not a great design in the long-run (but I'm sure there are reasons it was developed this way).  I did ask an Instructure engineer about this a couple weeks ago, because it seemed weird to me too.  He said he was passing the thread along to the right people to take a look at, but no promises about an official reply or any potential changes.

-Chris

[xmoffatt]

Hey! I will try to answer your questions and clarify some stuff from the replies as well.

As Paul answered in the 1EdTech Slack, we are currently working on supporting this feature, and allowing a re-registration for updating a dynamically registered tool.

> when the tool moves to a new domain, how can I update Canvas so that existing links send their messages to the new location?

As Chris detailed below, it _really_ depends on what you mean by "links". If you mean placements, like "my tool is showing in the course nav", then updating the DR tool using the future re-registration flow will help. Currently, deleting and re-creating the developer key will also work. I know that is not ideal, but also consider that "changing the tool's domain" is a pretty fundamental change for the tool!

If by "links" you mean content items created from deep linking (which I see from replies you are not using, so that makes this easier), then changing domain will break many of those existing content items, because the whole matching process from "I have an LTI launch url" to "I have the right tool to launch it" is built around matching on the tool's configured URL and domain, which is why changing the domain can be such a big deal. Which means that even if you had a non-dynamically-registered tool, if you changed the domain and all the fundamental URLs, those content items _still_ would not work any more. Luckily, you don't have to worry about this 🙂

> So, as dev keys created in other ways can be updated, it seems like dynamic registration is best avoided.  I have not yet been able to discover why dynamically registered dev keys are being treated differently from others.

The main reason that they are treated differently is that they are backed by a different database model, and as part of that we made some choices about what parts of the config are owned by the tool and shouldn't be changed by the admin (at the risk of becoming a "different" tool). I realize that without the update re-registration flow this is very inconvenient, and we are working to remedy that and make this a lot easier for you! The new Canvas Apps page will make it a lot easier to update things about DR keys and soon, to ask the tool for an updated registration as well.

> If I cannot update the URLs associated with the developer key, is it possible to create a new one and migrate all links associated with the old one to the new one?  Or some other solution such that existing links will continue to work?

Yes! You can delete and re-register the tool with the different domain. the old "links" (placements) will be gone, and replaced by the new placement configs from the new tool with the new domain - so to your canvas users, it will look and function the same. that is safe and very doable!

[svickers2]

Thanks for the helpful explanations.  I appreciate that a domain change is a fundamental change, but I am currently working on a tool which is being moved into AWS and retaining the old domain is not an option.  But my issue also applies in simpler situations, such as when the endpoint for a tool's public keyset changes, or its initiate login URL.

With regard to your last paragraph, I am assuming that all the old placements which "will be gone" are not automatically replaced by new ones for the new tool registration, but must be manually recreated in each course (or using API calls), which would mean they have a new resource link ID and so will not be recognised by the tool.  Or am I missing some way of avoiding this?

[xmoffatt]

Yes, absolutely - our hope is that allowing for the tool to re-register and provide updates will fix those kinds of more simple cases.

Okay, you have me confused on this one. You said upthread that your tool is _not_ using deep linking, but it kind of sounds like it is? what exactly do you mean by placements/links that need to be recreated? Can you point me to examples? when I say "placement", I mean that the tool will show up in the list for link_selection. That will happen automatically when you install the new tool. But it sounds like you are talking about content items _returned_ from the link_selection placement, like module items. Those are not placements, and if that is the case then yes you are using deep linking, and no those content items/links will not be automatically replaced. They will break. But! You could edit them using the "Update an LTI Resource Link" API endpoint to match the new launch url and (crucially) the new context external tool id from the new tool install (docs here). that would allow you to keep using the same links with the same resource link IDs. Does that describe your situation?

[svickers2]

Thanks for the reply.  By link I was meaning something like when an external tool is added to a module, or an assignment based on an external tool is created.  These can be created with and without using deep linking, but in either case they seem to record their own launch URL (target link URI) which cannot be left blank when it is the same as the launch message URL defined in the tool configuration.  So I agree with your suggestion that the only way to update the existing links will be to manually (or via the API) change their launch URLs.