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:
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:
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?
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.