Can you access SIS Data via a User Authentication Token?

[barbaracoen]

Does anyone know if you can access SIS Data (in particular the Course SIS ID), via the API, when using a User Authentication Token (vs an Admin token)?  

The reason we're trying to do this is because there is a bug in the Enrolments API - it does not return completed enrolments for closed courses, so we're trying to work around the problem.  We can get the data using and Admin token, however due to the API Throttling/Constraint (API Rate Limiting ), we'd like to access this via the User token instead so that we don't hit the constraint.

Appreciate any ideas.

Thanks
Barbara

[pklove · Accepted solution]

Using a user token won't get around throttling.  Each token has its own limit, so this will be throttled anyway.

By "admin token" do you mean a user token you have added for an admin user?  Or do you mean a token obtained using a developer key?  The first would be no different to a "user token" - its just that its for an admin user and so you have their permissions.

Are you sure your application will reach the throttling limit?  Unless you are making lots of parallel requests this is unlikely.  If you think you will exceed the limit on your admin token, can you simply add another one (or two) and use those?  Throttling is based on the token "not the account, instance, or user" (https://community.canvaslms.com/docs/DOC-8381-api-rate-limiting ).

[barbaracoen]

Hi Peter

Thanks for your response ... the theory is that if we use a User token we definitely won't hit the constraint, however if we use an Admin token there is every chance that we will.  I understand that we can generate extra admin tokens but it would be even better if we could access via a User token as we will never reach the limit for a single user and we are trying to extract user specific enrolment data.

The other part of my question is if an authenticated user (STUDENT) can access SIS Data - I've set the permissions to allow students to read SIS data but we don't seem to be getting the data we expect back through the API.  In particular we want to get the Course SIS ID for every course in which the user enrolled.  Any thoughts?

Thanks again for coming back to me.

Barbara

[pklove]

Hi Barbara,

Sorry, not much help, but I can confirm that for a non-admin user if I call /api/v1/courses I don't get back the sis_course_id for the courses where they are a student.  Its there if they are a teacher.  And changing the "Read SIS data" permission for each role does not make any difference.

Peter

[barbaracoen]

Thanks Peter. I'm very impressed getting a reply from so far away (I'm in Ireland)    

Thanks a million for taking the time to respond and you have triggered another idea ... will let you know how we get on as it might be useful to someone else.

Barbara 

[ag3811]

We use User tokens (generated with a developer key and OAuth) to get data for some of our LTI tools, like the Photo Roster and the Mail Tool.  Teachers can read SIS data by default.  Contrary to Peter's experience, changing the "Read SIS data" permission for TAs does get SIS IDs when we make API calls.  This means we don't have to program parallel queries, so we never hit the rate limit.  Let me know if I can help with more specific information!

[pklove]

Hi Angus,

My post referred to the permission not making any difference for students and teachers.  It didn't mention TAs, so I don't think your experience in contrary.

Do you get the SIS ID for students?

Peter

[stuart_ryan]

Hi  @barbaracoen ,

When we started out, I was worried about this also, we had some parallelism in our interfaces which use the API, so this was something we needed to consider.

There were a few of things that we came up with as possibilities to ensure we did not run into any issues:

1. Opt to use sequential processing only - by doing things in a sequence, such as a loop, and waiting until one call had finished, before sending off the next, you avoid the rate limiting entirely. The bucket is to stop a flood of requests from a single 'application' or 'user' so to speak. Hence, sequential is not an issue. As pklove identified this same concept applies to the user token. The documentation suggests a user token as in theory if you had 1000 students who needed to do something via the API concurrently, they each have their own API ratelimit 'bucket' and therefore would not get throttled. The best example I could give is the way I anticipate the mobile apps work. Rather than a single API key for a mobile app for an account, when a user logs in they get their own user token which is used for the API. That way when each student uses their own mobile device, it is parallelising the requests on their own API keys. 
2. To further expand on pklove's thoughts the second option we had (and I concur with) was to use a different admin API token per request type - you could (if you had a significant need to do parallel processing) use a different API key per API request type. For example if you need to get course details, you use one API token, if you need to set course details you use a second API token. There are other implementations of this, but I would anticipate this is the most common.
3. Do minimal parallelisation - more on that below.
4. Parallelise and gracefully handle the rate limit - if you are planning to run parallel queries, you can (and I dare say should) gracefully handle the rate limit, set a 'sleep' time and then try again when the rate limit has gone away. This allows you to handle the issue in a programatic way.

The option we went for was options three and four. Personally, if you are doing anything other than sequential processing, I think it is good practice to gracefully check for, and handle the rate limit error. In our instance we decided to run 5 threads in parallel, with the rest of the operations in those threads running sequentially. That gave us a good hybrid of performance, along with ensuring we would not hit any API limits as the most we have running at once is 5 API calls on a single toekn. We have thrown several thousands of students in over a short 5 minute period without issue.

If you are able to share a text description (or even brief diagram) of the flow you are trying to achieve, then we could confirm if you are likely to hit the limit. However, I had the same concerns coming in first time, then on deeper inspection we found that the rate limits were not a concern, provided they were appropriately considered, designed, and coded for.

Would love to hear more about the bug and what you are attempting as a work around.
Cheers,

Stuart