🔗 Build a Roles and Permissions System for Phoenix - Part 2

In the first post of this mini-series, we learned how to implement basic permissions for your schemas, how to group them into roles, and how to assign the roles to our users. We used the role to check a user's permissions in our Phoenix Controllers. Our controllers lie at the outer bounds of our system and adding the permission checks here is a good first step, but we can do better.

The second security layer of our RAP will be the restriction of queries. This layer aims to prevent data leaks by filtering out query results that the user shouldn't see. What the user shouldn't see depends on your use case, but we will implement two restrictions as an example:

For external users, our queries should return only the data that belong to the requesting user. For internal users, our queries should hide the data of other internal users. Only special internal users (e.g. HR Managers) are allowed to see such data. Internal users can see the data of all external users though. For example, customers of our company (external users) should only see their own invoices and addresses, but a customer support employee (internal user) should be able to see the invoices of all customers and their addresses. That employee shouldn't see the addresses of other internal users though, only special internal users (e.g. HR Managers) can do so.

Okay, that's enough theory. Let's write some code!

continue reading on peterullrich.com

⚠️ This post links to an external website. ⚠️