In .NET LTI Project - Part 1 - Connect to Canvas we got an app wired into Canvas, but it really doesn't do anything yet. It was a simple exercise in how to configure Canvas to recognize your application.
The next step is to understand the launch request. When a user clicks on the link in Canvas to access your application, Canvas is going to send a request to your web server with a bunch of variables. Let's take a look at those variables and what they mean.
You might want to take tag this document from IMS Global as a point of reference:
IMS Global Learning Tools Interoperability™ Basic LTIv1 Implementation Guide
Inspect Your Launch Request
If you're using the tutorial from Part 1, go to you HelloWorld controller and place a break point on the return view(); statement. Attach to the w3wp.exe process to start debugging and click the ltiDemo link from the admin navigation panel.
Once you have caught the break point, add the following watch variable for Request.Form.AllKeys
Place break point on the return view(); statement in the Index() method, and compare the list of variables you receive there. Basically you are comparing the difference between the data you receive when you launch from the admin navigation panel vs. the course navigation panel.
You should see a difference in the variables associated with the course launch request vs. the admin launch request. Many of the variables are the same, but there are differences.
The standard LTI variables are defined in the IMS Global documentation here:
IMS Global Learning Tools Interoperability™ Basic LTIv1 Implementation Guide
Of great importance are the oauth_* variables, which are critical for authentication. We'll get into these when we tackle the oauth piece of the puzzle.
There are also "custom" Canvas variables, which you can research here:
LTI Variable Substitutions - Canvas LMS REST API Documentation
The Canvas API document uses "dot" notation instead of underscores. For example, the Request.Form variable is "custom_canvas_api_domain", and in the API document it is "Canvas.api.domain".
Take a look at both the IMS Global document and the Canvas API document and think about how each of these variables could be of use to you as you identify users, their roles, and the courses the parts of Canvas they are requesting from.
- How can you use these variables to enforce different levels of user access in your app?
- Which variables would you use to expose a set of features in your app to a student vs. an instructor?
- How would you make sure you don't push an update to production from a launch request received from beta, or test? Or the other way around?
Conclusion
Take a few minutes to launch your app from different locations in the Canvas UI, and note the differences in the variables that you receive. Also take a look at the values. This is also a good opportunity to think about how you want to parse these values out of the Request object for lookup in other parts of your application. A dictionary could be a useful way to allow for easy lookup of these variables later. Or maybe you prefer a dynamic object for easy serialization to/from json. How you store these variables is important as you start to think about how you are going to manage your session state.
Food for thought:
If a user has multiple tabs open and launches multiple instances of your LTI app, how are you going to keep track of which course they are launching from and make sure you don't mix course information? Definitely something to start thinking about.
Something like MemCached might be useful.
If you do not use cloud services, I have used this product on my local machine in the past: NoSQL Database | Couchbase
Ok, so we're getting to the point where we'll need to attack oauth.
I'll try to work on a walk through that makes sense.
Part 3 is published here: .NET LTI Project - Part 3 - OAuth
A basic Visual Studio project is published here: LTI Demo Project
