Restricting access to content that is delivered client-side in a Gatsby site takes a few steps. We use Netlify Identity to handle user authentication and reach router to build our auth-restricted client-side application.
Instructor: [00:00] We have our site and we can log in and log out. Our next step is to create an authentication-restricted dashboard area so that we can create our to-dos. We'll start by creating a navigation item.
[00:29] Now we've made a few changes. The first changes we made were to introduce a nav element with a couple links inside. That's home and dashboard respectively. The home page is the one we're currently on, and the dashboard is the page that we're about to create.
[00:46] We've also included an extra link. If the user is logged in, that uses the user's full name. We haven't done anything with this yet, but it will show up if the user is logged in, as you can see here.
[01:00] Notice that we've done this by introducing an event handler for the login and logout events, where we set the user on login and we set an empty user on the logout. Now that we can get to the dashboard page, we'll have to create one so that we don't get a 404.
[01:16] To do this we'll use a plugin called gatsby-plugin-create-client-paths. Since the dashboard is going to be authentication restricted, it should only be a client-side route as opposed to a route on the server that renders when we build. This plugin makes it easier to set that route up.
[01:31] In gatsby-config create a new plugins key, and resolve to gatsby-plugin-create-client-paths. In the options we'll say that everything under the app prefix is going to be handled by our application.
[01:45] We can now create an app.js under source pages, which will be the entry point to our client-side app. For our client-side app, we'll use the router that ships with Gatsby, which is @reach/router. Note that if you see "cannot read property create element of undefined," it may be because the @reach/router docs destructure React from React.
[02:04] React is the default export, so we don't need these extra braces. Now that we now have an application redering at /app, it only renders dash. Note also that we don't really have a way to get the user. If we log in and then go to the dashboard, we can see our user name.
[02:20] If we refresh the page our user name isn't there. Note that we can fix that by copying and pasting the initialization logic in the event handlers from one page to another. That's not really great, because we'll have to do that for every page that we want to access the user on.
[02:36] We'll pull this logic out into a React Context and set it in a Provider. In the root of the site, we'll create a new file called IdentityContext. We'll set the value to use an object with the identity of netlify-identity and a user of Undefined.
[02:52] Then we can take the useEffect logic and move it into our Provider. This will now initialize netlify-identity for us like we did before, while also setting the login and logout handlers. We'll also need the useState for setting the user. Now that we have our Identity Context, we can go into wrapper element and use it.
[03:20] In the Identity Context, we'll also want to export the actual Context. This will let us useContext later. This makes our application code a lot leaner, while still keeping the state around for multiple pages.
[03:33] Note that if you set Exports.Provider equal to the React Component directly, the React ESLint hooks fail for no real reason. We can satisfy ESLint by setting the Identity Provider equal to the React Component that we've set up here, and then exporting it later. Back in our application, we can see that the new logic works. Note that we'll have to make the same changes in our home page.
[04:01] In the home page, we also use the open function, so we'll destructure that off the Context as well, and we'll get rid of the Log User button. Now our dashboard and our home page both use the new Provider that we've created. Our user is now always a useContext away. We've encapsulated that logic to be used across multiple pages.
[04:20] Finally, now that we have our user encapsulated in the Provider, we can render a different route based on whether the user is logged-in or not. We'll go back to our home page and copy and paste some of the code we wrote earlier. Note that while the import flux [inaudible] button, and we'll also have to get Netlify Identity out of the Context.
[04:48] Finally, we should add a Log Out button to the dashboard. We can do that by copying in the same navigation logic that we have in our home page. Remember to import NavLink from Theme UI. Now you can log in from the home page or the dashboard.
[05:09] Our Netlified user data is encapsulated in a Context that we can use across different pages. When you log in, you get access to the dashboard, which is authenticated, and if we log out, shows us unauthenticated page. Remember to commit the authentication logic that we implemented and push it so that it deploys on Netlify.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!