DEV Community: Corina Udrescu

Authentication with Nodejs and JWTs - a simple example

Corina Udrescu — Wed, 26 Jan 2022 08:35:40 +0000

When it comes to JWTs, most tutorials help you build a full implementation in Node. However, they rarely stop to show just the basics - just the esssential parts that need to be there for JWT authentication to work, and nothing more.

This article aims to give a simple, straightforward overview of the steps needed to add JWT auth to a Node app.

We'll start from an unprotected API with a super secret resource and go towards securing it with JSON Web Tokens (JWTs).

What we'll build

Our API will only contain two endpoints:

/login - will return the token
/super-secret-resource - the information that only logged in users should access

Step 1: Creating a Node API with Express

Let's start from the barebones - just an API that returns a very important resource, that should only be accessed by logged in users. This endpoint should return 401 Unauthorized if the user is not logged in. Since we don't have the /login endpoint yet, it will just always return 401 for now.

Create a new folder for the project, run npm init -y to initialize the project and run npm install express to install express.

Next, create a server.js file for the node app. In its simplest form, this is how the API would look:

// server.js
const express = require("express");
const app = express();

app.get("/super-secure-resource", (req, res) => {
  res
    .status(401)
    .json({ message: "You need to be logged in to access this resource" });
});

app.listen(3001, () => {
  console.log("API running on localhost:3001");
});

To start the API, run node server.js in the console.

To check that the endpoint cannot be accessed, run curl:

curl -i localhost:3001/super-secure-resource

// Will output:
// 
// HTTP/1.1 401 Unauthorized
// X-Powered-By: Express
// Content-Type: application/json; charset=utf-8
// Content-Length: 62
// ETag: W/"3e-eJQzoUv1nk6AKpsmnnXBmFvKrI4"
// Date: Sat, 22 Jan 2022 09:05:53 GMT
// Connection: keep-alive
// Keep-Alive: timeout=5
// 
// {"message":"You need to be logged in to access this resource"}

The -i flag tells curl to also return the headers, so we can see the HTTP status code.

Notice the 401 HTTP status code - which stands for "Unauthorized" - and the message we returned from the endpoint.

Step 2: Return a JWT token on successful login

Next, we want to allow users to login and send back a verified token if their user and password are correct.

Since setting up a full database of users and password is out of the scope of this article, we'll just hardcode an admin/admin user and check for that as an example.

The first step is to install the npm jsonwebtoken module. This package will help us sign and verify JWT tokens.

npm install jsonwebtoken

Then, the endpoint will look like this:

const express = require("express");
const jsonwebtoken = require("jsonwebtoken");

// The secret should be an unguessable long string (you can use a password generator for this!)
const JWT_SECRET =
  "goK!pusp6ThEdURUtRenOwUhAsWUCLheBazl!uJLPlS8EbreWLdrupIwabRAsiBu";

const app = express();
app.use(express.json());

app.post("/login", (req, res) => {
  const { username, password } = req.body;
  console.log(`${username} is trying to login ..`);

  if (username === "admin" && password === "admin") {
    return res.json({
      token: jsonwebtoken.sign({ user: "admin" }, JWT_SECRET),
    });
  }

  return res
    .status(401)
    .json({ message: "The username and password your provided are invalid" });
});

Some things to note here:

the JWT_SECRET should be an unguessable long string
the part that actually does the signing is: jsonwebtoken.sign({ user: "admin" }, JWT_SECRET)

We can check a token is returned with curl:

curl -X POST http://localhost:3001/login --header "Content-Type: application/json" --data '{ "username": "admin", "password": "admin" }'

// {"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiYWRtaW4iLCJpYXQiOjE2NDI4NDQ0NTR9.O_710gS-6t9nmqvW0_E1GlP7MdoLMFR85GXUUeskNi8"}

You can decode the token and see what it contains on jwt.io

Some things to note:

The "Header" of the token contains the algorithm used - in our case, the algorithm for signing the token is HS256
You can input your secret in the bottom right to have jwt.io verify the token signature (if the signature is verified, it means the token hasn't been tampered with)
Besides the { user: admin } which we encoded, there's also another property there - iat, added by the jsonwebtoken library; this stands for "Issued at" - i.e. when the server created the token (as Unix timestamp)

Step 3: Send the token to the /super-secure-resource and verify it to allow access

Now let's use that token to allow the logged in user to access the restricted resource!

In order to do that, we will need to send the token to the API (as an Authorization header) and then verify the token on the server:

curl -i localhost:3001/super-secure-resource --Header 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiYWRtaW4iLCJpYXQiOjE2NDI4NDYzMzV9.gQj-qjoQwtvyU2XzER6yiT-T4DwYphjMft-kogW978c'

// Will return:
//
// HTTP/1.1 200 OK
// X-Powered-By: Express
// Content-Type: application/json; charset=utf-8
// Content-Length: 69
// ETag: W/"45-9rvFFDk8vkfruRd3Ok0vQNGIdMk"
// Date: Sat, 22 Jan 2022 10:15:03 GMT
// Connection: keep-alive
// Keep-Alive: timeout=5
//
// {"message":"Congrats! You can now accesss the super secret resource"}

Why this works:

By signing the token, you ensure that the server can check that whatever token it receives, was created by itself
If you try to tamper with the token, you'll invalidate it! The server will tell it's been tampered, so it will not authorise you!
Try it out: take the token, change it in jwt.io and try again -> it will fail!

Make it yours!

I specifically kept the source code for this article very barebones. Go ahead and improve it!

Add nodemon to automatically reload the server when you change the API
Add nodeenv and move the JWT_SECRET to as an environment variable
Setup an actual database with users and passwords
Add more endpoints and move the code that verifies the token in an express middleware

How to check if your component rerendered - and why!

Corina Udrescu — Mon, 11 Oct 2021 18:00:55 +0000

If you're like me, you're probably using console.log a lot to check the React rendering lifecycle of your components 😅 When it rerendered, why - was it a setState or something else ?! - or even just to get a better handle of React fundamentals.

This can work fine at the beginning - but what if you want to answer bigger questions about your app - like whether using Context has an impact on the performance of your app? Or simply, what if you're tired of scrolling through tens of console.logs figuring out what executed when?

Then it's time to use the React DevTools! Not only do they allow you to visually see what components rerender, but you can also investigate what caused each rerender and easily spot what components are taking longest to render.

Using React DevTools to highlight what components rerendered

There's a checkbox well hidden in the React DevTools settings that allows you to visually highlight the components that rerendered.

To enable it, go to "Profiler" >> click the "Cog wheel" on the right side of the top bar >> "General" tab >> Check the "Highlight updates when components render." checkbox.

Then just interact with your app as usual and watch it all light up ✨

Using React DevTools to find out the cause of a rerender

Now that you can see your component rerendered, the next question is .. why?

There's a very handy tooltip that shows up when hovering over a component in the "Flamegraph", that shows the reason for a render under the "Why did this render?" heading.

To see this, you need to record a "Profiler" session.

For example, if you your component re-renders after you click a button, you can click record to start profiling, click the button in question, then stop profiling and see the details of what happened when the button was clicked.

Here's how to read the profiler output:

In the top right you have the number of React commits - each bar represents a moment when the React component tree changed and a change was commited to the DOM
The "Flamegraph" shows the component tree and what changed - "grey" means the component did not rerender

Hovering over each component will reveal why it rendered in the "Why did this render?" subheading.

Possible values you can expect to see as reasons for a component rerendering:

"This is the first time the component rendered."
"Context changed"
"Hooks changed"
"Props changed"
"State changed"
"The parent component rendered."

You'll notice that sometimes the reason is not very detailed - simply saying "hook changed" instead of the details of what hooked changed. This is expected and it happens because sometimes the DevTools simply does not have access to that information or because it would be too slow to retrieve.

When you click a component in the "Flamegraph", the right sidebar will update to show all renders of that component instance and why they happened:

Bonus tip: See at a glance what components took longest to render

It took me a while to figure this one out, but the colors in the "Flamegraph" actually have a meaning: "cool" colors - like shades of blue - signify the component took little time to render compared with everything else and "warm" colors - like orange and red - signify the component took a longer time to render 😀

flamechart color - yellow took longest

Notice how I just said "more time" or "less time" to render - that's because what is slow or fast is relative to your specific app and total render time. So it could be that a "yellow" component rerendered very fast if it's part of a simple component tree, or for a "blue" component to actually take a very long time to render if the whole app is very slow.

Bonus tip: See what DOM changes actually happened

Even if a component rerendered, it doesn't mean that any changes were actually applied to the DOM - it could be that the output of render was the same as before, in which case React does nothing. But how can you check? How can you visually see what DOM parts were rerendered?

The Chrome DevTools have a very useful setting for this - "Paint flashing". This will highlight all elements of a page that were "repainted". To enable it, you need to click the "Settings" menu, then "More settings" and then "Rendering" and check the "Enable paint flashing" checkbox.

Try it out for yourself!

You can find the sample app used for this blog post at https://stackblitz.com/edit/react-3cmy6b. (Make sure to click "Open in New Window" in the top bar in order to see the app outside of the StackBlitz environment, which makes it easier to profile. )

Can you figure out why all "cards" render when just one is clicked? And moreover, can you fix it? 😀

Fork the code and share your solution in the comments below!

Should you switch to useReducer or is useState enough for your needs?

Corina Udrescu — Mon, 13 Sep 2021 07:40:47 +0000

The useReducer hook is usually recommended when the state becomes complex, with state values depending on each other or when the next state depends on the previous one. However, many times you can simply bundle your separate useState statements into one object and continue to use useState. So when is the extra boilerplate required for useReducer justified after all?

When there is complex business logic

Structuring your code with actions allows for better encapsulation of business logic.

Also, it allows you to separate the description of the action (WHAT happened) from how the state should update because of it (HOW it should be handled).

A simple example to showcase this is updating the state when the user navigates to the next page on a paginated list view.

With the hook, this could look like this:

setState(state => { ...state, page + 1})

However, with actions, you can add more semantics to this event and encapsulate the logic:

// action
dispatch({ type: 'GO_TO_NEXT_PAGE' })
// reducer
case 'GO_TO_NEXT_PAGE':
  return { ...state, page: state.page + 1}

In the future, if you decide something else needs to happen when the user clicks the "Next page" button, you only need to update one place: the reducer.

While this is a simple example, for deep nested values or arrays of objects, abstracting away the state update logic can be very valuable.

When there are many ways the state can be updated

In most situations, there are only a couple events that update the state - take for an example a simple login flow, where you only need to track loading, success and error states. In this case, useReducer does not add that much value.

However, imagine a more complex login process, like multi-factor authentication, where the user needs to be guided over several screens - to enter his password, to enter the one time token - and you need to handle all sorts of edge cases like the QR code expiring, the password being incorrect etc.

In these situations reducers can really make it easier to follow the different component states and how they change.

When you need better debugging

Tracking how the component state changes after each setState is generally harder to do than just having all changes go through a reducer.

Regardless if you prefer using console.log or breakpoints, it's easier to add just one log/breakpoint in the reducer as opposed to one for each call sprinkled across the component.

And if you ever decide to switch to Redux, the Redux DevTools make for a great debugging experience.

To wrap up, you don't need to jump to useReducer as soon as you have multiple useState hooks in your component. Many times, it's enough to just bundle all the state values in one object. However, if it becomes hard to figure out what's going on, useReducer can be a very helpful tool!

If you're interested to read more, I've found these articles helpful in my research:

What options do you have for deploying a frontend-only React app to production?

Corina Udrescu — Sat, 12 May 2018 03:53:00 +0000

If you’ve ever wondered how to deploy your React app once it’s ready, you probably know that figuring this out can become confusing really fast.

Most articles go over detailed instructions on how to configure nginx, how to configure reverse proxies. But do you really need any of these if you just have a frontend-only React app and are looking for the easiest way to deploy?

If you think about it, once you build a React app for production, you’re basically left with a bunch of html, js and maybe image files. This means you can deploy it to any hosting that supports static file hosting.

Let’s go over some of the options!

Firebase

Website | How to

Firebase is a Google service that also offers static site hosting. It comes with a free tier you can start with, deployments are done with their CLI and they support SSL, CDN & custom domains out of the box.

Netlify

Website | How to

Gained a lot of traction recently. It’s a point and click interface that is very powerful, allowing you to configure automatic deployments based on a specific branch, to have ‘test’ deploys for feature branches and even do A/B testing of your website all from their UI.

Surge.sh

Website | How to

Surge is also a static site hosting service specifically targeteted at frontend developers. Supports custom domains, even with the free plan.

Zeit Now

Website | How to

Deploy your website made as easy as running now in a folder. Supports a lot of options through their CLI. Also a great choice for deploying node apps or or server-side rendered React apps.

Github Pages

Website | How to

This is a classic and probably the first choice if you just want a hosting for your library’s main page. Can be used for other stuff as well though since it has great integration with git and more.

Since it’s not explicitly targeting SPAs, you might run into issues when setting up the routes.

AWS S3 buckets

Website | How to

This is the most complex of the options described so far, however comes with greater flexibility and might come in handy if you already use AWS for other things. Use it together with AWS CloudFront and AWS Route 53 for a full Amazon solution (described here).

Heroku, Digital Ocean, Azure or Amazon EC2

You can always deploy your app to a custom server instance. This requires tweaking with the server, but gives you more control. You will need to install and configure a web server on the machine - either nginx, apache, IIS or whatever you’re more comfortable with - and point it to serve your static files.

Though it’s tempting to use a custom setup if you already have a machine available that you’ve used for other projects, I highly recommend you try one of the options above to take your workflow to the next level :)