Handling permission in redux

Question

Using a node-redux stack. We have action creators on the client side and reducers + redux state on the back end. I have the following proposal to implement permissions:

1. Actions are created client side, these may be malicious, even from authenticated users.
2. Actions are sent to the server.
3. The request is authenticated server-side and the users permissions ascertained.
4. The actions pass through the redux middleware which lives inside the node server.
5. Middleware checks the users permissions against permission specified for the action type.
6. If the user has the correct permissions for the action then the reducers create a new redux state (which also lives on the server).

Problem:

Each action type is coupled to a set of permissions, this means that we need to take great care creating our reducers so that we never allow an action to do more than it should. With multiple devs on the team and a large application I am not convinced this is sufficient.

Questions:

Is there a good resource/link with a good discussion on handling permissions with redux.

Is redux sufficient for handling complex permissions?

If we check permissions as outlined above are there any problems that I have not mentioned and is there a better way of approaching this while still using redux?

Answer 1

Redux is "permission agnostic". Redux is just a framework for coordinating actions that update the application state; it contains no opinions or recommendations on how to approach permitting those actions.

Answers

Is there a good resource/link with a good discussion on handling permissions with redux.

Here is one.

Authorization is a very difficult thing to make general proclamations about, since it very much depends on the business needs. Are you using roles? Are you just requiring authentication? Can users have multiple roles, or just one? How do multiple roles interact? These are not questions with one answer.

Is redux sufficient for handling complex permissions?

This is like asking if JavaScript is sufficient for handling complex permissions. It doesn't really make sense.

From one perspective, is it "possible" to handle complex permissions: yes. Redux will not restrict any permissions scheme you wish to implement at the action level, since actions are just functions that call dispatch (another function). You can use actions to stop the dispatch call for any reason.

From another perspetive, does redux provide an out-of-the-box mechanism that can handle complex permissions without any additional patterns or tools: no. Redux does not even attempt to address this concern, it is entirely up to you.

If we check permissions as outlined above are there any problems that I have not mentioned and is there a better way of approaching this while still using redux?

There are most certainly problems you have not mentioned, since you have not completely outlined your implementation. As they say, the devil is in the details. How you accomplish what you have described will determine what other problems you encounter.

Is there a better way? "Better" is about as vague as you can get. What are your parameters for "better"? In a trade-off between development speed and run-time performance, which would you prefer? In a trade-off between number of server calls and permission granularity, which would you prefer?

All you have said is that you are checking actions on the server. Without knowing what your authorization model is, its impossible to say if a better way exists, even when you precisely define "better", because we don't know what you are doing.

However, given the information you have, and assuming that doing the check server side is both necessary and time-saving (another big assumption), I would say (as weakly as I possible can) yes, there will be additional problems. To name a few:

• Latency. Redux expects the entire app state, including the value of input fields. Your model checks the server on each action, so developing in a stricly redux manner every keystroke will go to the server to ensure that it is allowed to update the input. This will make user interaction very slow, and very frustrating.
• Bandwidth. This is going to consume a lot of bandwidth, for the reason as above.
• CPU. This is going to be very server CPU intensive, for the reason above.

A big win in client-side applications is that the server only does the work it absolutely has to: serving data (in a minimal format like json), and verifying requests to update data. You are going to be taking on the additional work of running all of your clients. This is a questionable tradeoff to reducing the boiler-plate of writing a REST api.

This will also lock you into your action api, and redux. A REST api has the advantage of being client-agnostic. If you change from redux, or just reorganize your actions, the REST api on the server wont need to change (or at least, wont need to change as much). This is going to make refactoring, even if you stick with redux, painful. Whether or not this overcomes the pain of writing a REST api is impossible to say, but its something to consider.