Custom submission field in Canvas API

[Dfez00]

Hello,

I am making a solution which uses Canvas API. My goal is to make assignments in my solution that propagates to Canvas, but I'm having an issue with the Submission Type. My idea is that the students will be graded in the solution which will also be propagated to Canvas, but I see that the submission types (online entry, file upload, etc) also lets the student try and submit it manually through Canvas, and I don't want that since I want them to access my solution through a link in the description.

I see that there is a "No submission" option in the Assignment, but then the API doesn't let me make the POST to create a new submission for that student.

Any thoughts? Thank you.

[chriscas]

Hi @Dfez00,

I just wanted to give you a quick initial reply here...  I'm sure others in the group will be able to chime in with their thoughts as they have some time as well.

You may want to look at the LTI standard (the latest version of the standard is 1.3) for your app, as it's more universal and designed for almost this exact purpose.  You'll see one of the assignment submission types available is "external tool" and that will then list the installed LTI apps for the particular Canvas instance.  The various LTI specs will allow for students to complete the assignment in your app, and then for the grade to be passed back seamlessly to Canvas.

While it's possible to do things via API, I think you'll increasingly find Canvas administrators unwilling to accept that kind of integration due to security issues and the kind of access they'd have to grant to make it happen.  If this is an app you're just making for yourself, that may not be as much of a concern, but if it's something you want to make available to others, I figured I would mention this now so you don't spend a lot of time going down the road and have to backtrack later.

Hope this helps a bit

-Chris

[Dfez00]

Thank you @chriscas for answering.

I have already tried an LTI solution but I wanted to try a more granular approach with the way we can create assignments and submissions externally while using the API in the background. I also expect to have a token with very limited scope so our clients see that we will only have access to the endpoints needed and not more.

With your response I see that there is no way to add an assignment with no submission but to be able to do so via API. I'm thinking if there could be any other type of Canvas content I can create through the API (Discussion, pages..) that can be graded and submitted via a Student in the API without being able to submit it manually in Canvas.

I can understand that there is no solution there too and I might just have to deal with the fact that they can manually add submissions.

Again, thank you.

-Danny

[Dfez00 · Accepted solution]

Hello all, I was able to fix my own problem and maybe for future questions it could help.

Turns out I don't need to even make the submission at all. You are able to send the grade API call to an assignment with no submissions, since the assignment you grade (as a teacher) is tied to the student, not the submission (since you grade all submissions too).

Hopefully this helps someone else, cheers 🙂

[JamesSekcienski]

@Dfez00 What are you trying to do with API access that you can't do with an LTI?

I would recommend that you still follow @chriscas's recommendation to make this as an LTI and not rely on the API for grade updates.  If students are completing assignments in your tool on an external website, it should be connected to Canvas using LTI standards to send the grade to Canvas.  This would also help to ensure your tool only has access to update scores on assignments that are connected to your external tool.

Designing an integration that only uses API, means that you would get access to update scores for all assignments in courses your access token has access to, including assignments that aren't associated with your tool.  This creates an unnecessary security risk in which scores for assignments that aren't associated with your tool could potentially be modified too.

[chriscas]

Exactly!  @Dfez00, if you plan on making this a commercial, or even an open-sourced or free app for others to use, I would highly recommend you to follow the industry standard LTI approach.

I can tell you as a Canvas admin myself that an app using an admin user API token would basically never get approved for use at this point in most public higher-ed institutions in the US.  If you're using a developer key, that is slightly better, but would still face a lot of scrutiny and in my opinion would get rejected by most institutions.

Without more info, it's hard to give a ton of advice.  I guess it would be really good for us to know if you're developing this app for one specific school or do plan on having it available to a wider audience than that.  If the former and the school approves of your approach, maybe you can ignore our advice.  if it's the latter, I think it would be a good idea to pause and potentially rethink the approach.

I know you mentioned LTI wasn't flexible enough for what you were trying to do.  Could you give any examples of what LTI won't let you do that you'd like to?  Hopefully you could give a few examples without revealing any trade secrets about your app idea.

In the end, you can decide how you want to make your app.  Folks in the community here have a lot of experience in different LMS-related roles though so there might be some things here you have't considered yet.  Even if you accept security risks yourself, it's generally the school/university using the app that makes the security assessments on their own, and those assessments have been getting more and more strict through the years.

-Chris

[Dfez00]

Hello! With LTI access we have limited control of things we are able to do with our external solution. We want to have a more streamlined approach that connects to Canvas without the hassle of LTI.

I understand that the token, even with the enforced scope of the few endpoints we will use, will have access to all courses. I understand that will not happen if the developer key is installed in the course, is that correct? I understand the security risk regarding that.

[chriscas]

Hi @Dfez00,

A Developer API Key can only be installed at an account level, not in a single course.  A Developer LTI 1.3 Key, on the other hand, can be deployed to a single course, multiple courses, a single account, or multiple accounts.  This can definitely be confusing for people new to Canvas, but I hope spelling out this distinction right now helps!

I made a reply about while I think you were posting this asking if you can give more info about what you're trying to do and what limits you're running into with an LTI approach.  Any info you can provide would be useful.  There are some great people here who can give great advice on good/better/best approaches, but I know they are going to need a more info to understand what's going on.

-Chris

[Dfez00]

Hello @chriscas 

I understand, I got confused with the LTI App install that can be done in the course. We have had some trouble in the past with the LTI regarding consistency while sending grades and having a myriad of errors while connecting our solution to Canvas. Our approach to use the API was to streamline this process and make it better for the client. We have taken steps in order to make sure we are not asking more authorization that we need for our clients.

Besides enforcing the scope in the general developer api key in the admin account, we will install an LTI App that will live only in the courses that implement our solution that will log in the user into our system. We have a tight system in place where we have to pre-onboard that user into our system so we make sure that not just anybody is able to join, but the users we decide. In this way we make it so only teachers with their corresponding tokens are the ones who gives us access with the token.

We will use that token to create assignments on their side and grade their students, so when they use our solution, through the LTI App, it connects to us and then we send the grade back to Canvas.

As you can see it is not our intention to have a token with admin permissions, and even if we have, we will not have those endpoints in our enforced scopes, which I believe in total will be around 3-4 endpoints only.

I would love to know how do you feel with this solution, thank you for the insight.

- Danny

[JamesSekcienski]

@Dfez00 

In my opinion as a Canvas admin, saying that you had trouble with getting your LTI to send grades consistently is not a strong reason to accept this approach.  If you need assistance with getting the grade exchange to work for your LTI, you could also contact the Instructure Partnership Team as they offer LTI Advisory Support services: https://www.instructure.com/partners

Since you are already making an LTI to handle the user authentication to log into your system, I would expect the grade exchange to be a part of that.  A separate Developer Key for API access should not need to be set-up for this since grade exchange is a part of the LTI standard.  In addition, it is a poor user experience to have your tool interacting with and updating assignments that aren't set-up with a submission type of External Tool and linked to your tool.

Even though you have been using scopes on the key, it still creates an unnecessary risk giving your tool that level of access just to update grades for your tool's assignments.  The scopes are not able to limit the access to specific assignments, so once you get access to update grades, your tool would have access to update any grade for any assignment that the Canvas authorizing user (teacher) has access to grade (where the Developer Key is installed).

[sendres]

Hi @Dfez00,

I will echo what @chriscas and @JamesSekcienski are saying: LTI is the standard for a reason and you should exhaust every effort to use that approach. As a Canvas admin, I would be extremely hesitant to install your solution if it requires API access.

Just this spring at my university, we met with a well-established assessment platform vendor. Our security audit showed their solution could be implemented using LTI 1.3 but hasn't been. When we pressed them on this, they acknowledged as much and claimed an LTI 1.3 implementation was "on their roadmap." But they couldn't give us any specifics, such as a timeframe, whether it was currently conceptual or under active development, or how many people were assigned to the project. We disapproved the integration.