Fast feedback when building a software-as-a-service application is critical.
This is especially true in the early days of building. The quicker you can get a working version of your product in the hands of users, the faster you can collect input and make decisions based on that input. Doing so can make an incredible difference in the success of your online business. One option is to use a platform to collect emails and notify them that the application is ready to test, but wouldn't it be nice to have them sign up for the application directly first?
In this article, you'll learn how to configure Clerk to allow users to sign up for your application but restrict their access until you explicitly allow it. You'll also learn how to create a page to interact with the user's info in Clerk to grant them access to the application.
💡 To follow along with this article, you'll need a free Clerk account, as well as Node.js installed on your computer.
Cooking with Clerk is an open-source web application built with Clerk and Next.js that will be used to apply the techniques outlined in this article. The application is an AI-powered recipe generator that uses OpenAI's API as part of the generative process. During development, we don't want to allow anyone to use it since it can easily start increasing our cost to use the OpenAI API.
If you want to follow along, clone the repository to your computer and follow the steps outlined in the readme.md file to get your local environment set up. The source code can be found at https://github.com/bmorrisondev/cooking-with-clerk.
The remainder of this article assumes you will be following along using the waitlist-article branch, however this is entirely optional. It also assumes you've already signed in with your own account.
To build the waitlist functionality, we'll be performing the following actions:
Users in Clerk can be configured with various types of metadata that can store information about that user in JSON format.
We can take advantage of this storage mechanism to assign the various flags to users of our application:
isBetaUser can be used to determine if the user has access to test the application while in early development.isAdmin can be used to determine if the user has access to the admin dashboard that will be created to allow users into the beta.Let's start by setting the isAdmin flag on our own account. Open the Clerk dashboard and navigate to "Users" from the left navigation.
Select the user you want to allow admin access to, then scroll to the bottom and locate the Metadata section. Click the first "Edit" button to edit the users' public metadata.
Paste the following into the JSON editor and click Save.
Now even though public metadata is accessible from the front end, we'll be modifying the Clerk middleware to determine where to redirect the user once they've signed in. This means we'll need to add the public metadata to the claims so we have access to it before the user is fully loaded in the front end.
To do this, select "Sessions" from the left navigation, then click "Edit" in the Customize session token section.
Paste the following into the JSON editor and click Save.
Every token minted from now on will contain the JSON that is saved to the user's public metadata within the claims of the token.
The Clerk middleware runs on every page load to determine if the user is authenticated and is allowed to access the requested resource using the isProtectedRoute helper. For example, the following middleware configuration will protect every page that starts with the /app route and the /api route:
Clerk will automatically parse the session claims (where the public metadata is) within the auth() function, which means it's accessible to us during this process like so:
Using this, we can determine if the session claims contain our isBetaUser flag. Update the src/middleware.ts file to match the following:
From now on, any user that does not have isBetaUser defined in their public metadata will instead be redirected to a page that simply tells them that they are on the waitlist. It's also worth noting that since this check is performed after auth().protect(), this function will only run if the user is logged in with a Clerk account, preventing it from running when not needed.
To see this in action, start the project on your computer by running npm run dev in your terminal and navigate to the URL displayed in the terminal (the default is http://localhost:3000, but may differ if another process is using port 3000).
Click "Sign In" in the upper right and log in with the user account you used during setup. You should be able to access and test the app with no issues.
Now sign out using the user menu, and sign in again with a different account. You'll notice that instead of accessing the application, you are redirected to /waitlist. This is the middleware at work!
Now that we've built the capability into the app to require the isBetaUser flag to be set, we need a way to set this for users interested in testing the app. Sure, it can be done from within the Clerk dashboard, but we can also take advantage of the Clerk SDK to create a page that allows us to perform this action within the app. Start by creating the src/app/admin/page.tsx file and paste the following code into it. This will create a page at /admin that displays an empty table.
Next, we're going to create a client component that will display a row for each user within the table named UserRow. Before we do that, however, we need a server action that the UserRow component can use to interact with the Clerk Backend SDK to toggle the isBetaUser flag within a user's public metadata. Create the src/app/admin/actions.ts file and populate it with the following:
Now create the src/app/admin/UserRow.tsx file with the following contents. This will be used to render each user in a row on the admin page.
Finally, update src/app/admin/page.tsx by importing the new component and adding it to the table:
Open the app in your browser again and navigate to /admin, you should see a list of the users from your Clerk application displayed in a table. Notice how only the account you manually added isBetaUser to during the first part of this guide has the toggle enabled under the Beta enabled? column.
Now, if you toggle another user on and log in again with that account, you should be redirected to /app instead of /waitlist! Furthermore, if you open the application in the Clerk dashboard and review the user's public metadata, you should see that isBetaUser has been enabled via the dashboard.
At this point, we've effectively built the waitlist functionality, as well as created a polished experience for controlling the flags enabled on the user account. The problem is that the middleware is set up only to protect /app and not /admin, so anyone with the beta flag could technically access the admin panel. With a few minor tweaks to middleware.ts, we can also prevent users from accessing the admin panel:
Now whenever someone tries to access /admin without the isAdmin flag set in their Clerk user metadata, they'll get a 404 page instead of the admin panel.
Clerk user metadata can be extremely useful for storing various information about the user.
This is simply one example of how to use metadata. If you need some more inspiration, we also have a blog post showing how to build an onboarding flow using a similar approach that I recommend reading!
Do you have an interesting way you've used user metadata in your application? Share it on X and let us know by tagging @clerk!
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。