I am developing an application using Angular and REST API and I'm facing a problem concerning user access right.

The application runs this way:

  • A user signup
  • The same user creates his organization
  • He invites people to join the organization
  • Every users of the organization are able to manage many different things, like tasks, agenda, etc...

This flow can appear many, many, many times.

Question 1

Concerning the global rights, I m mean there, the fact that a user of an organization A cant access the task of an organization B etc...

Does it exist a pattern to avoid me, in each of my API methods, to check the organization ID, meaning that sometime, I have to work through multiple other objects and tables or collections, implying many databases requests (and more with reflexive classes)?

Question 2

Concerning the roles, should I test the role each time a user sends a request (meaning, that I have to request the role table and check if he can access this API endpoint)? Or does it exist another pattern there too?

1 Answer 1


No, basically you can't avoid this. Only way could be to have a independent database for each organization, otherwise every single request you make would have to include organization id to make sure users get only data they are allowed to see or modify.

This even if a request directly includes a specific resource id. Say you have a resource order. Now you have a user logged in who has full permission to see and modify orders of his organization. In the first step he retrieves a order form with id 123. He modifies the order and posts the result. You have a RESTful URL like /order/123 for the POST request.

Now in your controller you could be tempted to load this order. Say your framework puts the ID from the url in a variable orders_id. You simply load the order with SQL like this (very simplified):

SELECT * FROM orders where id = 123;

But what, if the user changes the ID and sends it to URL /order/456? Without checking user and organization this POST request would simply pass. So at a minimum you would have to first load the user and then get the organization and the (still simplified) SQL would have to do something like this:

SELECT * FROM orders where id = 123 AND organization_id = 456;

So even if a single resource could be identified by its ID, you can't rely on this. The same for everything else you ask.

Similar for roles, while it would be possible to include the role as an attribute to the URL or payload this would not be safe.

Even if you have different databases you would have to load the user data and ensure that the right database is used. Otherwise you get similar problems.

Also the users id should of course be stored encrypted in the session data so a user can't change it like other data and act as a different user.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.