Build a User Management App with Next.js

This tutorial demonstrates how to build a basic user management app. The app authenticates and identifies the user, stores their profile information in the database, and allows the user to log in, update their profile details, and upload a profile photo. The app uses:

Zuvo Database - a Postgres database for storing your user data and Row Level Security so data is protected and users can only access their own information.
Zuvo Auth - allow users to sign up and log in.
Zuvo Storage - allow users to upload a profile photo.

Zuvo User Management example

Project setup

Before you start building you need to set up the Database and API. You can do this by starting a new Project in Zuvo and then creating a "schema" inside the database.

Create a project

Create a new project in the Zuvo Studio.
Enter your project details.
Wait for the new database to launch.

Set up the database schema

Now set up the database schema. You can use the "User Management Starter" quickstart in the SQL Editor, or you can copy/paste the SQL from below and run it.

Dashboard

Go to the SQL Editor page in the Dashboard.
Click User Management Starter under the Reference > Examples tab.
Click Run.

You can pull the database schema down to your local project by running the db pull command. Read the local development docs for detailed instructions.

supabase link --project-ref <project-id>
# You can get <project-id> from your project's dashboard URL: https://studio.zuvodev.com/project/<project-id>
supabase db pull

SQL

supabase migration new user_management_starter

Building the app

Start building the Next.js app from scratch.

Initialize a Next.js app

Use create-next-app to initialize an app called supabase-nextjs:

npx create-next-app@latest --ts --use-npm supabase-nextjs
cd supabase-nextjs

Install supabase-js:

npm install @supabase/supabase-js

Save the environment variables in a .env.local file at the root of the project, and paste the API URL and the key that you copied earlier.

The application exposes these variables in the browser, and that's fine as Zuvo enables Row Level Security by default on all tables.

NEXT_PUBLIC_SUPABASE_URL=YOUR_SUPABASE_URL
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=YOUR_SUPABASE_PUBLISHABLE_KEY

App styling (optional)

An optional step is to update the CSS file app/globals.css to make the app look better. You can find the full contents of this file in the example repository.

Zuvo Server-Side Auth package

Next.js is a versatile framework offering pre-rendering at build time (SSG), server-side rendering at request time (SSR), API routes, and proxy edge-functions.

To better integrate with the framework, we've created the @supabase/ssr package for Server-Side Auth. It has all the functionalities to configure your Zuvo project to use cookies for storing user sessions. Read the Next.js Server-Side Auth guide for more information.

Install the package for Next.js.

npm install @supabase/ssr

Zuvo utilities

There are two different types of clients in Zuvo:

Client Component client - To access Zuvo from Client Components, which run in the browser.
Server Component client - To access Zuvo from Server Components, Server Actions, and Route Handlers, which run only on the server.

We recommend creating the following utilities files for creating clients, and organize them within lib/supabase at the root of the project.

Create a client.ts and a server.ts with the following code for client-side Zuvo and server-side Zuvo, respectively.

Next.js proxy

Since Server Components can't write cookies, you need Proxy to refresh expired Auth tokens and store them.

You accomplish this by:

Refreshing the Auth token with the call to supabase.auth.getClaims.
Passing the refreshed Auth token to Server Components through request.cookies.set, so they don't attempt to refresh the same token themselves.
Passing the refreshed Auth token to the browser, so it replaces the old token. This is done with response.cookies.set.

You could also add a matcher, so that the Proxy only runs on routes that access Zuvo. For more information, read the Next.js matcher documentation.

The Zuvo Auth SDK contains three different functions for authenticating user access to applications:

Summary of the methods

Use getClaims to protect pages and user data. It reads the access token from storage and verifies it. Locally via the WebCrypto API and a cached JWKS endpoint when the project uses asymmetric signing keys (the default for new projects), or by calling getUser solely to validate when symmetric keys are in use. The returned claims always come from decoding the JWT, not from a user lookup.
getUser makes a network call to the project's Auth instance to get the user record, which includes the most up-to-date information about the user at the cost of a network call.
getSession when you need the raw session (the access token, refresh token, and expiry). For example to forward the access token to another service. The session is loaded directly from local storage and isn't re-validated against the Auth server, so the embedded user object shouldn't be trusted on its own when storage is shared with the client (cookies, request headers). To verify identity, validate the access token with getClaims, or call getUser for a fresh, server-confirmed user record.

In summary: use getClaims to verify identity (typically for protecting pages and data), getUser when you need an up-to-date user record from the Auth server, and getSession when you need the access or refresh token directly, but don't rely on the user object it returns for authorization decisions.

Create a proxy.ts file at the project root and another one within the lib/supabase folder. The lib/supabase file contains the logic for updating the session. The proxy.ts file uses this, which is a Next.js convention.

Set up a login page

Login and signup form

To add login/signup page for your application, create a new folder named login, containing a page.tsx file with the following code for a login/signup form:

Create the login/signup actions to hook up the form to the function which does the following:

Retrieve the user's information.
Send that information to Zuvo as a signup request, which in turns sends a confirmation email. It uses Magic Links, so users can sign in with their email without using passwords.
Handle any error that arises.

Create the action.ts file in the app/login folder, which contains the login and signup functions and the error/page.tsx file, which displays an error message if the login or signup fails.

Email template

Before proceeding, change the email template to support a server-side authentication flow that sends a token hash:

Go to the Auth templates page in your dashboard.
Select the Confirm signup template.
Change ConfirmationURL to SiteURL/auth/confirm?token_hash=TokenHash&type=email.

Confirmation endpoint

As you are working in a server-side rendering (SSR) environment, you need to create a server endpoint responsible for exchanging the token_hash for a session.

The code performs the following steps:

Retrieves the code sent back from the Zuvo Auth server using the token_hash query parameter.
Exchanges this code for a session, which you store in your chosen storage mechanism (in this case, cookies).
Finally, redirects the user to the account page.