DEV Community

loading...

Keeping things safe, using React Router !

arthurvfain
・2 min read

Cybersecurity is extremely important, and when writing apps, keeping things water-tight is harder than ever, with different ways of finding backdoors and other methods of accessing unauthorized information more prevalent, protecting our resources is as important as ever. One of these methods that I encountered is protected routes, through the use of React Router Dom.

At it's most basic level, implementing a protected route is simply placing every component that needs special authorizations in another component that accesses state from the parent and only renders those pages if the parent's state is set to true for a log in.

In order to do this, we must first have all the resources that we want to protect made into components that are passed into our "protector" component as props using a render functionality.

I see this protector component as a "ghost" component almost, as it doesn't have a set shape and takes the place of whatever component is passed to it as props.

See the example below for a boilerplate Protector component.

import React from 'react';
import { Route, useHistory } from 'react-router-dom';

function Protector ({ component: Component, user, ...rest })
{
const history = useHistory()

  return (
    <Route {...rest} render={props => {
        if (user) 
        {
          return <Component {...rest} {...props} />
        } else {
          history.push(/logIn)
        }
    }} />
  )
}

export default Protector;
Enter fullscreen mode Exit fullscreen mode

In order for this to work, there must be a few things to understand and implement elsewhere in the app.

First thing that was new to me, was the use of the render prop for the Route. This is key, because just as previously we passed things to Route using the component prop, it would evaluate only once. This does not work, as we need the route to update each time a new prop is passed to it, and this is only done with render. As a side effect, authentication and authorization are checked each time a new component is rendered through the Protector component through its Route.

Next, what else was new to me, was the use of "...rest" in prop syntax. I have never seen this before and I'm glad that I encountered this. It is a .js keyword that automatically fills in all the props from a component being passed in and passes them to the next child in the hierarchy. This is particularly useful here, as it is used to pass everything passed into the Protector into the render in Route.

Finally, there need to be all the helper methods added in App.js, including all the handleLogIn's and handleLogOut's that will interface with the backend to make sessions that will then set the state in app that will satisfy the "user" conditional in the Protector's ternary render, and will not allow any of the protected pages to be shown unless "user" or "session" return truthy.

All in all, although there are a few new things to learn to make Protected routes work with React Router, it really is a clean, flexible, and fairly safe way to make resources inaccessible unless the necessary conditions are met.

Learning about this tool and all the necessary implementations has been interesting and I look forward to using them in my future projects.

Cheers.

Discussion (0)