Periodic, May I?

COLE SMITH, API GUY

When I was first told to write a permissions system for our new API, I was excited. When I was told I had free reign of the project, I was a bit nervous. This was uncharted territory for me, but I was pretty certain on how I wanted to go about it.

Initially I figured, “why not switch over the object the user is interacting with?” That way, I would have all the information on the object and could decide if they had permission by inspecting it. I found some interesting examples online of people taking interface{} objects and attempting to type cast them to various other user defined types. It looked pretty promising and felt like exactly what I needed.

I implemented a solution along those lines and it seemed to work pretty well. Once an object was successfully cast, the program then determined what call was being made. If the object was cast as a Bookable, and the call was “get_bookable” the program would then look at the user (and other various factors,) and decided what they were allowed to do based on their user role. In the case of an admin user, if the bookable they were trying to get had the same Marketplace name then they would be allowed to retrieve it. User roles with less permissions had to have a common provider subdomain.

This all seemed to work well, and everything was going fine until I went to write permissions for a call that interacted with multiple objects. Checking permissions individually was too costly, having to type cast each was not a good solution. When I brought this up at a stand up meeting, my boss suggested just switching over the call (“get_bookable”). This solution seemed obvious only after hearing it.

For some reason I had decided even before starting this project that I would check the object first. So simply by switching the order to checking the method, then type casting the object the permissions system became more flexible and much faster. Since I had convinced myself of how I wanted to go about this before I began, tunnel vision prevented me from seeing the obvious answer when I became stuck.

I am sure there would have been some merit in finding a solution to my original design, but I doubt it would have ultimately been better than switching gears and simply checking a string. This new design gave us more flexibility in that each individual call has its own method in the permissions system.

Having a permissions system that checks each call individually is important. Where the original iteration was grouping all calls that interacted with the same type of object, this new iteration is checking on a case by case basis, literally. Just because “get_bookable” and “get_bookables” both interact with bookables does not mean they both need the same information to check permissions. The new iteration was able to handle this easily.

Related Articles