I'm currently working on a small project and trying to implement authorization for database operations effectively. I've thought about two main methods:
1. Performing explicit checks for each data type, like `canEditBusiness`, which requires an additional database round trip for each API endpoint. Although this feels more organized and straightforward, it does come with the drawback of needing that extra database call.
2. Incorporating the authorization check directly into the database operation itself. For instance, the `editBusiness` function would include logic to verify whether the user has access based on their userId. However, this makes the queries more complex since I'll need to integrate the check into each related query instead of having a centralized function to verify business membership.
I'm sure there are many methods to approach this, so I'm interested in hearing what others think are the best practices for setting up authorization in a clear and manageable way.
5 Answers
I prefer pulling all permissions on each API call and using middleware to check them for every endpoint. It might mean an extra call, but it ensures you always have the most accurate permissions, and separating this logic into middleware keeps everything organized.
I’m a bit confused about the difference between the two options. Can you clarify?
I would strongly suggest going with the first option. Generally, database queries are pretty cheap, and maintaining clear and understandable code will save you headaches down the line. It's worth that extra round trip to keep things clean and simple.
Definitely stick with option 1. The additional database call is minor compared to the potential bugs you'll create by scattering authorization logic everywhere. By centralizing authorization checks, you'll find it much easier to audit and maintain—less chance of accidentally leaving a security hole.
I just took over a project where the previous developers shoved a lot of business logic into stored procedures. It’s tough to debug and test, so I believe your option 1 is a good approach. It would allow for easier unit testing since you could simply mock the response for `canEditBusiness`.
Sure! In option 1, you have a separate function that explicitly checks if a user has access, making it clear what you're verifying. In option 2, the authorization logic is baked into the database query itself, meaning you have to intertwine it with your selections, which can complicate things.