I’m trying to wrap my head around various app sharing scenarios that I hope to deploy before I retire. The more I can bullet-proof the processes, the better. To help me think about this clearly, I’m going to list the scenarios here, starting with the easiest and working my way up to the muddle currently swirling in my brain.
Level 0: Don’t share, don’t use the API, anonymous.
I’m pretty comfortable with this one. It only requires the blti library I adopted from Dr. Chuck, and I don’t need to distribute key : secrets. I’ve used this to create editor buttons and assignments. I was surprised to learn that even an LTI assignment can be launched anonymously and still pass a grade back to Canvas. I don’t fully understand how that works, but it does. I always require a key and secret when using grade passback, but I’m not sure whether or not that is necessary.
Level 1: Don’t use the API, anonymous, shared
I’ve only done this with one app so far, but it seems to be working out. The app sends a score back from one of the very first simulations I ever created, the UD Virtual Compound Microscope. Since grade passback does not require the API, all I need to store in my database is the key : secret pairs I give to people who want to use it. I have a google form I use to collect and respond to requests. There is a script in the form that composes the sql statement needed to populate the database, and send reply email, but I don’t run it automatically. I like to check first to make sure that all uses are non-commercial. Still, turn around on requests has been pretty fast so far.
Level 3: Use the API, don’t share.
Using the API is a huge step up. It’s a lot harder. It’s a lot scarier. It’s a lot more powerful. I find myself reaching for the API more and more, but also dreading the consequences more and more. However, as long as you don’t have any intention of sharing your code, using the API is pretty straightforward. All I need to do is include my CanvasAPI library, grab an existing admin-level auth token from my database, and I’m good to go. Currently I have several apps that COULD be following this workflow, but only one that actually uses it. Peer Evaluation.
Level 4: Use the API, prepare to share, but don’t.
The rest of my API dependent tools are hooked into a structure I put in place for deploying my developer super-power: requesting tokens on-the-fly. This may have been a mistake, but as long as a valid access key is properly located in the database, the whole token request sequence is never triggered, and the app behaves like a level 3 app. The only difference is that I worry about database corruption if something were to go wrong. There are provisions is there for deleting tokens, replacing exisiting database entries, and of course, writing to the database at all is far scarier than just reading from it. I should probably push everything that is actually in use at UD back to level 3, and maybe I will.
Level 5a : Use the API, don’t share, issue single-use tokens on the fly
This is where I am right now. I have an app that I’m playing with on our campus that requests a temporary token each time it is launched. It has a delete token button you can use to automatically delete, but even if you don’t do that, there is little danger of token abuse, because the token does not get stored. I’ve had a devil of a time getting this to work, but I THINK it is working now. I wish I knew of a way to delete the token even if people exit Canvas without using my button. If anyone knows of a way to do that, please comment!
Level 5b : Use the API, share, and issue/store tokens on the fly
I have one app that I think is doing this successfully, storing instructor level courses for each context in which it is launched. Users should only be asked to authenticate once, since the token is stored. In theory, if an admin authenticates, no one else in that domain should need to. One of the problems with working on this particular branch is that I don’t have access to any other domains I can test on.
Level 5c: Use the API, prepare to share, issue/store tokens on the fly
I have a version of one of my level 4 apps that does this. The big difference between issuing on the fly and using a dedicated token is that when you have an instructor-level token, your API access is constrained…mostly in a good way. So, for example, when pushing grades into the gradebook via the API using an admin token, you have to masquerade as an instructor in order to have them show up as the grader. In most cases, you won’t even succeed in getting the grades posted unless you masquerade, since admins don’t seem to have the authority to grade assignments. When using an instructor token, you don’t need to masquerade. Your grades will show up as though they had been submitted by the token holder. This is not quite the same thing as showing up as the logged in user, since some courses have more than one instructor, and the same tokens are issued per course, not per instructor. Since instructors don’t have the power to masquerade as each other, it’s a fly in the ointment.
The other big difference is that there are just so many more places for things to go wrong. Also, it is way, way harder to test.
Level 6: The holy grail
Ideally, you’d want to have a single set of files that handles all of the above scenarios on demand. I am still hoping to get to this level some day. So far, even the baby steps I’ve attempted have been a struggle.