Before you go, check out these stories!

Hackernoon logoRole based authorization in React by@vcarl

Role based authorization in React

Author profile picture

@vcarlCarl Vitullo

Inspired by a recent conversation I had on Reactiflux, where I go by vcarl. I’ve also republished this on my personal blog.

Authentication and authorization are both common problems when writing an application. Authentication answers the question “who are you?” while authorization answers the question “are you allowed to see that?”

Somebody recently asked how to accomplish role-based authorization using React and react-router, and linked to a post describing one way to go about it. Essentially, the post suggests simply passing a list of roles that are allowed to see a given route, and checking whether the currently logged in user is one of those roles within your route handler.

That would work, but I see a few problems with it.

  • Single responsibility principle violations
  • Unnecessarily passing data through react-router
  • No reusable code

So how can we do authorization in a way that gives each component a single job to do, is self contained, and is reusable?

One way we could improve upon the above blog’s code would be to encapsulate the authorization logic in its own component—with a function child to prevent components from mounting if the user isn’t authorized—and render that from your route handler.

This gives us reusable authorization logic, which is a step in the right direction. We could even have the Authorization component load the user itself, so all it took as props are the allowed roles. But each route would still “own” the fact that authorization is taking place, which doesn’t feel right.

But there’s another option. A higher order component, often abbreviated as HOC, could move the authorization logic completely outside of the route handler. Assuming the Authorization HOC loads the currently logged-in user on its own, it could look like the following:

I almost didn’t include an implementation of the Authorization HOC, because it depends on what you’re using to store your data, whether you want to show an error message or redirect somewhere else on failure, which router you’re using, etc. There are a lot of unknowns, and I want to focus on the pattern rather than the implementation details. The important thing is that it inspects the currently logged in user and renders the wrapped component they have a sufficient role.

Because it doesn’t matter when the HOC is applied, we could move that function call into the router configuration.

Update: It’s been pointed out that wrapping a component in a HOC within render can cause a lot of problems, and as a rule, shouldn’t be done. In every case, replacing the inline HOC function call within component={} should be replaced with assigning it to a variable outside the render method.

const RouteWithAuthorization = Authorization(YourRoute, ['roles'])

For further reading on why this is a bad idea, check the React documentation. Back to the original post.

Great! Now there’s isn’t a hint of authorization logic in our route handler, nothing is being passed through react-router, and all of our allowed roles are defined in a single file. But you know what, if we have a lot of routes, that’s going to mean a lot of duplicated role definitions.

Let’s make two changes: Flip the order of the arguments we give to the HOC, and “curry” the function. Our HOC becomes a function that returns a HOC. This type of function call should look familiar if you use Redux, as it’s the same mechanism connect uses.

Now, we can “seed” our authorization HOC with different levels of allowed roles, eliminating the need to define allowed roles over and over.

There, that’s better. Now we can define a set number of roles in advance, and we could have a router configuration like this:

Users are able to see everyone, managers can edit users, and admins can add new users. It’s clearly apparent what the intent is by looking at the usage, and each part of the code has a single responsibility.

Edit: To reiterate above, creating higher order components within render will cause problems with how React calculates diffs. In the final example above, the User(User), Manager(EditUser), and Admin(CreateUser) portions should be extracted from the render method and assigned to variables.

Of course, client-side authorization is only one part of it. The backend should always enforce user roles as well, because all data on the client can be changed from the devtools.

Do you disagree, or think you have a way to improve this? Let me know! I’m vcarl in Reactiflux. This is not a best practice, this is an idea that I thought would solve problems people are facing in the real world. I published this as a blog post instead of a library because everyone’s use case is different. Maybe in your app, the Authorization HOC passes the current role as a prop into the component it’s wrapping. Maybe one of the curried arguments is a component to render if authorization fails. Maybe instead of a higher order component, it’s a component with a function child that gets the role and whether authorization succeeded as arguments. Maybe instead of an array of allowed roles, you pass a function with the signature user => bool.

As a P.S., React has a number of idioms that let you write really expressive, concise code once you’re familiar with them. Higher order components, function children, and (basic) currying are concepts with very simple code: each of them takes only a few lines, but once you figure out of what types of problems they solve, you can combine them in ways that make them extremely powerful.

I’m also on Twitter where I mostly tweet tech stuff, and Reactiflux, where I help answer React questions.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!


Become a Hackolyte

Level up your reading game by joining Hacker Noon now!