cancel
Showing results for 
Search instead for 
Did you mean: 
j_causby
Community Member

Returned value for 'is_favorite' field on Get Courses dependent on Auth Token used?

Hi Devs,

While developing for an lti tool integration and using get courses for a user api with the ?include[]=favorites parameter, it is successful returning the boolean values for the courses, however it's returning false for all courses when I use an admin user auth token, and it's returning the correct true/false designations when I use an auth token created on that user.  

When using user's auth token after favoriting this course in the Canvas UI: 

286209_Favorites_user_auth.png

When using admin's auth token:

286210_Favorites_admin_auth.png

Is this the intention of auth tokens?  Is there a way to create an auth token or to authenticate to get this information?

Thanks,
Jerry

Labels (2)
3 Replies
James
Navigator II

Interesting question. The way description reads, you would think it was the favorites for the user specified in the :user_id. It could be a bug or designed that way, it's too early in the morning with not enough sleep the last week and the first day of the semester starting in about an hour for me to think about it right now.

You may be able to get the Favorites API for the list for a different user. It only recognizes self, but you should be able to specify the as_user_id query parameter to pretend to be someone else, assuming you have masquerading rights.

j_causby
Community Member

Since we already are retrieving the profile for the user, I just tacked on the `as_user_id` parameter as you mentioned and it worked!  I would like to know why it seems that an admin auth can see all the privileged info for a users courses _except_ if it's `is_favorite`.  It does seem like a slight bug, but the masquerading workaround works fine.  Thanks!

I did a quick look in the source code. I didn't see anything in the courses controller, which is the one being called, that handles favorites (it's documented as an include), so it's probably handled by the code for the favorites controller, which would make sense in the context of keeping related code together in one file. In that code, it's coded as @current_user rather than @user, probably because the favorites are only returned for the current user -- which is overridden by the as_user_id= parameter, but I guess not by just asking for a user.

Being able to figure out why it's doing what's it's doing is not the same as saying it's doing what makes the most sense.