Authentication

Client-Side Protected Routes and User Registration

September 22, 2020

Welcome to Part 16 of Up and Running with FastAPI. If you missed part 15, you can find it here .

This series is focused on building a full-stack application with the FastAPI framework. The app allows users to post requests to have their residence cleaned, and other users can select a cleaning project for a given hourly rate.

In the previous post, we brought the redux and react-redux libraries into the mix for global state management. Doing so made it easy for us to handle authentication state on the client and ensure that users can authenticate against our FastAPI backend and stay logged in.

We still haven’t provided a registration mechanism for new users, nor have we protected routes from users who aren’t currently authenticated. Let’s handle that in this post. On top of that, we’ll ensure that each user has a personalized profile page to view their user stats.

Protecting Routes

Whenever we sign into our application we’re redirected to the profile page - which is nice! However, if we sign out, we’re left on that page. That’s going to cause problems if we don’t handle it, so let’s begin there.

Go ahead and create a new component called ProtectedRoute.js.

Add the following code to that new component:

This component connects to our redux store, checks to make sure that we have a currently authenticated user (by casting user.email to a boolean), and renders the LoginPage component if that’s not the case. If all is well, it renders whatever component is passed in along with the associated props.

After we export the component,

We can use it in our routes like so:

Try navigating to the /profile route without an authenticated user. See how we’re shown the LoginPage component instead of the ProfilePage component? That’s how our ProtectedRoute in action.

It’s weird though. Sorta seems like we actually navigated to the LoginPage as there’s no indication in the UI that we weren’t allowed to access that page. Let’s notify the user as to why they’re seeing this page.

This is the perfect situation for the EuiToast component! Well, we’re actually going to leverage the EuiGlobalToastList component that stores a list of toasts. They’re super useful, so check out the documentation here .

Now unauthenticated users that navigate to the /profile page will be shown a login screen and have a nice message panel in the bottom right that explains why they’re seeing what they’re seeing. If the user hasn’t been loaded into redux yet, we show an EuiLoadingSpinner component for a smoother user experience.

We’re going to need to return back to this component later on, but let’s move on for now.

Registering Users

At the moment we have a nice RegistrationForm component that doesn’t actually submit anything to our FastAPI backend. We’re going to need to replace our dummy registerUser function with a redux action creator, and make sure our reducer is set up to handle registration flow as well.

Let’s start on the redux side of things in the redux/auth.js file.

Alright. Quite a few things happening here.

First, we’re creating constants to represent the three states that could results from a user attempting to sign up. We then use those constants in our reducer to indicate how the shape of our auth data in the redux store should look under each of the defined conditions. Finally, we define a new action creator called registerNewUser that returns an async function.

The function begins by dispatching the initial request action - REQUEST_USER_SIGN_UP - and then makes an api request to the proper endpoint. If the request is successful, we dispatch the REQUEST_USER_SIGN_UP_SUCCESS action, grab/stash the access token from the response, and pass it to our fetchUserFromToken action creator. If anything goes wrong, we catch the error and dispatch the REQUEST_USER_SIGN_UP_FAILURE.

Sidenote: I realized as I started writing the code for this post that having the token available at res?.data?.access_token?.access_token is pretty silly. It will probably make sense to go into the backend and refactor that later on. We could also just take the user data returned from creating the user and update the store, but I’d rather stay consistent in fetching the user from the access_token.

This pattern follows closely in line with how we allowed users to log in, so it shouldn’t seem too out of place.

Let connect our RegistrationForm to the redux store and use our new action creator.

Ok, this looks pretty similar. We connect the component to our redux store and map the properties of the auth slice to the RegistrationForm. We also map the authActions.registerNewUser method to the component props using the Object-notation shorthand. If the user signs up successfully, they should immediately be redirected to the /profile page. Otherwise, we reset the password fields have them try again.

Try signing up a fresh user and check out our new registration flow in action.

Not bad! But there’s definitely some improvements that can be made here.

First of all, we’re not handling unsuccessful registrations at all and we’re starting to repeat ourselves in the redux/auth.js file. Before we do anything else, let’s address some of those issues.

Refactoring API requests

Observant readers will have noticed that we’re following a particular pattern on every request to our API. We issue the initial request, then handle either a successful response or an unsuccessful one. We have actions for each case, and chances are we’ll be replicating this process again and again.

Instead of continuing to write each new request by hand, let’s write a custom client to handle that for us.

Create a new file in the services directory titled apiClient.js and a new file in the utils directory called urls.js.

Our utils/urls.js file will be responsible for standardizing the url formats used across our app, so that’s a good place to start.

Open up the file and add the following:

Event though it looks like there’s a lot going on here, the end result isn’t that complicated. Let’s step through each function starting from the last one: formatURL. The function takes in two arguments, url and params, and uses the formatAPIPath and formatURLWithQueryParams functions to compose a full path to an API endpoint.

Let’s see an example of how it would work:

Besides removing the need for us to manually construct the full URL each time we call our FastAPI backend, this function standardizes the format of URLs in both production and dev environments. When we deploy our application, we’ll simply add the REMOTE_SERVER_URL environment variable and our code should work as is.

The formatAPIPath function just ensures that our relative path has a forward slash at the beginning and the end. Our formatURLWithQueryParams takes in an object representing query params passed to the endpoint, and formats them as encoded URI components. If none are passed or the object is empty, it returns only the base path.

Now, let’s construct the apiClient service that will employ these utils.

Now we’re talking. The getClient function takes in an optional token and constructs the proper request headers. Then it returns a simple object with GET, POST, PUT, and DELETE methods mapped to the appropriate axios api request method.

Our apiClient function is where all the magic happens. Before we outline each of the parameters, let’s see how we might actually use this function in practice. If we were to rewrite our registerNewUser action creator to use our new client, here’s how it might look:

Wow! That’s so simple. All we need to do is pass an object to apiClient with keys for:

• url - the relative path to the api endpoint
• method - the HTTP method used at this endpoint
• types - the three different action types we would dispatch at different stages of the request
• options - an object containing data used in POST requests and any query params
• onSuccess - a callback to return if the request succeeds
• onFailure - a callback to return if the request fails

Behind the scenes, the apiClient simply returns an async function that accepts the dispatch method as its only argument. That function grabs the user’s access token from local storage (if it exists), creates a client with that token, and then dispatches the initial REQUEST action to kick off the async flow.

The full api endpiont is then constructed using the formatURL util we defined a minute ago and we make the request inside a try/catch block. If the request is successful, we dispatch the SUCCESS action and return the onSuccess callback. In the case of an error, we dispatch the FAILURE action and return the onFailure callback.

Let’s actually go in and refactor the registerNewUser action creator for real this time:

A couple new wrinkles. We’re actually calling the dispatch function on the apiClient so that we have access to it in the onSuccess handler. This allows us to dispatch any additional actions in the onSuccess callback, making it easy to ask for the user’s profile after they’ve successfully registered.

With that out of the way, we can now do some proper error handling in our RegistrationForm component.

Handling Signups Using Duplicate Usernames and Emails

So what situations might we expect user registration to be unsuccessful? Well, besides a network issue, what happens when the user attempts to sign up with an email or username that is already taken?

Let’s find out!

Try signing up with these credentials:

• email : me@you.com
• username : person
• password : whateveryouwant

If everything goes well, we should be redirected to the profile page and have our user credentials displayed in the popover. Sign out and try registering with the same credentials.

Uh oh! That’s no good. The request fails, but there’s no feedback for the user. Inspecting the redux state tree tells us a bit more. The error attribute is currently holding an object with a detail key stating: "That email is already taken. Login with that email or register with another one."

It’s nice that we can see that, but we can’t leave users completely unaware of their errors. Try changing the email to something unused and see what error response is returned. We should expect to see “That username is already taken. Please try another one.”

Here’s where things get extra interesting. Enter in an email using this format: coder@. Our email validation on the client only looks for an @ symbol, so this should be valid. Provide an unused username and click Sign Up. The form submits, but it isn’t successful. When we inspect why, we see that the detail attribute on the error object is an array of information about why the request was invalid. Remember that pydantic is validating the body of the request on the FastAPI side. When the request body is invalid, we’ll get a 422 response code and an array of error objects detailing the issues with each field.

In our case, the object has a loc array, a msg, and a type. While each of these values is useful in determining what went wrong, they aren’t particularly user facing, so it makes sense to provide an error interface for handling responses from the FastAPI server.

Let’s go ahead and create another file in the utils directory called errors.js.

This file will be responsible for parsing the error message sent back by our FastAPI server and ensuring that we have a standardized format to display on the client side.

Let’s be clear here - this isn’t the GREATEST code we’ve ever written. It’s a quick and dirty error parser that is taking the place of writing a custom error handler in our FastAPI backend. We’re saving that for a future refactor, so don’t stress out too much if this doesn’t feel like a clean solution to our problem. It’s not meant to be.

In the extractErrorMessages function we check to see if the error sent back from the server is already a string. If it is, we simply use that error. If we get an array, it’s likely the result of a pydantic validation error. We pass each validation error to our parseErrorDetail function and handle each type appropriately. In the case of a path or query error, we’ve likely incorrectly formatted our API call and will want to handle that ourselves. However, when there’s an error validating a POST body field, we’ll map that field to the appropriate error message or return a default message.

Now we’ll do a quick refactor in our RegistrationForm component and display whatever error message is necessary.

We start by importing the extractErrorMessages messages function and calling it inside our component with the authError prop mapped from our redux state tree. We also create a hasSubmitted flag with React.useState that will indicate whether or not our user should be shown any errors stored with redux. Otherwise, they would see errors as soon as they loaded up any authentication form. That doesn’t make for a good user experience. We also ensure that when the user clicks submit, we set the hasSubmitted flag to true.

We create a new getFormErrors function that replicates the same functionality we saw with the LoginForm component. All that’s left is to update the EuiForm component to be invalid when the array returned from getFormErrors is not empty and then to render those errors after the user has submitted.

Let’s try it out one more time. We enter person@me and are shown a Please enter a valid email. error. We use an email that is already taken, and are shown a That email is already taken. Login with that email or register with another one. message. And finally, we try a taken username and are shown That username is already taken. Please try another one..

Fantastic.

Building Out A Profile Page Skeleton

Alright, now that our authentication flow is starting to come together, let’s spruce up our profile page to give the logged in user something to look at.

Simple enough. We connect the ProfilePage component to redux and map the user to component props. Then, we add a card with the user’s avatar (with a default name prop set to the user’s full_name or username) and add some relevant profile info. It also makes sense to go in and use the same defaults for the EuiAvatar in the Navbar component for consistency.

Since we’ll want to make a minor adjustment to the navbar anyway, let’s also head in there and adjust the handleLogout function as well. We’ll do this to wrap up the last piece of our basic authentication flow. When the user signs out, we’ll redirect them to the landing page instead of leaving them on the page they’re currently on. This way, they won’t see that Access Denied toast that pops up for trying to access the /profile page when they’ve just signed out.

We’ve ensured that whenever the user clicks the log out button, they’re signed out properly and redirected to the landing page. This makes for a better user experience anyway, so it only seems right. We also add the user’s username as a fallback for a missing profile pic in all sections.

And just like that, we’re done.

Wrapping Up and Resources

This concludes the set of introductory posts in the building of our front-end for the Phresh application. At the moment, we’re working with a pretty solid base. We’ve implemented a registration and login system using redux and axios, baked in routing with react-router, and styled a few pages with elastic-ui and styled-components. On top of that, we’ve brought in a few fancy animations with framer-motion.

We’re now ready to start letting users create posts and interact with our site. For now, we’ll end things with a few resources referenced in this article.

• Elastic UI toast docs
• Elastic UI horizontal rule docs
• Elastic UI avatar docs
• React Router DOM page
• Framer Motion docs
• Styled Components docs
• Axios package

← Previous Post

Managing Auth State With Redux

August 21, 2020

Next Post →

Consuming a FastAPI Backend from a React Frontend

September 25, 2020