Troubleshooting "fake" LTI OAuth Consumer Key Value

dan_hammari
Community Participant

LTI consumers who import thin common cartridge files (.imscc) very often run into the problem of having their LTI connections overridden with default credentials which have the word "fake" set as the oauth_consumer_key value. I often witness this behavior following this chain of events:

  1. Site administrator creates account-level third party app configuration with correct LTI credentials.
  2. Instructor imports a thin common cartridge into a course.
  3. During import, Canvas creates a new third party app configuration at the course level with default LTI credentials.
  4. Canvas appends a warning badge icon on the import report which indicates that though the cartridge import was successful, LTI credentials may need to be set for the third party app configuration it has just created.
  5. Instructor does not comprehend that a new third party app configuration has been created locally which either needs to have its credential values set or simply be removed so the account-wide settings are used instead.
  6. Instructor tries to use the newly imported LTI links and receives an error message from the content provider that the consumer key value provided is not valid.

When I receive complaints from customers who receive a "Your consumer key is not valid" error, I immediately check for the word "fake" as their oauth_consumer_key value in the LTI request. When I find this value I instruct them to remove any course-level instances of the third party app configuration that would override the account-wide third party app configuration.

Would it be possible to develop a tool that could help instructors and administrators detect when a third party app with default configuration values is being used? It would be most helpful if the cartridge import process could also detect that an account-wide third party app already exists before it creates a duplicate with default credentials at the course level. This could help prevent LTI launch requests with "fake" oauth_consumer_key values and their inevitable support requests to troubleshoot competing LTI configurations.