Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Jason-AML/MonzaSport-Nextjs/llms.txt

Use this file to discover all available pages before exploring further.

Monza Motors wraps Supabase Auth in two thin service modules — one for client-side operations (auth.client.js) and one for server-side session retrieval (auth.server.js). All functions use @supabase/ssr clients that handle cookie-based session management automatically. The client module (auth.client.js) instantiates a single shared createBrowserClient instance at module load time, while the server module (auth.server.js) creates a fresh createServerClient per request so that it can read the latest cookie state from next/headers.

​
Client-Side Auth Functions

File: src/services/auth/auth.client.js These functions run in the browser and must only be called from 'use client' components or event handlers. They use the browser Supabase client, which stores the session in a cookie accessible to the @supabase/ssr middleware for automatic token refresh.

​
signIn(email, password)

Authenticates an existing user with email and password using Supabase’s signInWithPassword method. 
import { signIn } from '@/services/auth/auth.client';

try {
  const data = await signIn('user@example.com', 'password123');
  // data.user    — signed-in user object
  // data.session — Supabase session (access + refresh tokens)
} catch (error) {
  console.error(error.message); // e.g. "Invalid login credentials"
}
​
email
string
required
The user’s email address. Must match a registered Supabase Auth account.
​
password
string
required
The user’s password. Passed directly to supabase.auth.signInWithPassword.
On success, returns the Supabase data object containing both user (the authenticated user record) and session (access and refresh tokens). The @supabase/ssr client automatically writes the session into the browser cookie so subsequent requests are authenticated.
BehaviorDetail
Returns{ user: User, session: Session }
ThrowsError with Supabase’s error.message on wrong password, unverified email, or user-not-found

​
signOut()

Signs the current user out by calling supabase.auth.signOut(), which clears the session cookie and invalidates the active token. 
import { signOut } from '@/services/auth/auth.client';

await signOut();
// Session cookie is cleared; user is fully logged out
BehaviorDetail
ParametersNone
Returnsvoid
ThrowsError with Supabase’s error.message if the sign-out request fails
After calling signOut(), redirect the user to a public route. Any server-side getUser() calls in subsequent requests will return null.

​
registerService(email, password)

Registers a new user account via Supabase’s signUp method. Unlike signIn and signOut, this function returns the raw Supabase { data, error } object rather than throwing, giving callers fine-grained control over the response. 
import { registerService } from '@/services/auth/auth.client';

const { data, error } = await registerService('new@example.com', 'password123');

if (error) {
  // Handle unexpected registration errors
  console.error(error.message);
}

// Detect a duplicate email address:
if (data?.user?.identities?.length === 0) {
  // This email is already registered — show an appropriate message
}
​
email
string
required
The new user’s email address. Supabase will send a confirmation email to this address if email verification is enabled.
​
password
string
required
The new user’s chosen password. A minimum of 6 characters is recommended to satisfy Supabase’s default password policy.
Supabase does not return an error for duplicate email registrations by default. Instead, it returns a data.user object with an empty identities array (data.user.identities.length === 0). Always check this condition in your registration flow to detect and communicate duplicate accounts to the user.
BehaviorDetail
ReturnsRaw { data, error } from supabase.auth.signUp
Duplicate emailNo error thrown — check data.user.identities.length === 0
Network / policy errorReturned in error field, not thrown

​
Server-Side Auth Functions

File: src/services/auth/auth.server.js This module provides session-aware user retrieval for the server environment. It creates a fresh server Supabase client on each call to ensure the latest cookie state is reflected — essential in Next.js 15 where each Server Component render may have a different request context.

​
getUser()

Returns the currently authenticated Supabase User object by reading the session from the request cookies. Returns null if no valid session exists or if any error occurs. 
import { getUser } from '@/services/auth/auth.server';

// Inside a Server Component or Route Handler:
const user = await getUser();

if (!user) {
  // User is not authenticated — redirect to login or return 401
}

// Use user properties:
console.log(user.id);    // Supabase UUID
console.log(user.email); // Registered email address
BehaviorDetail
ParametersNone
ReturnsUser object if authenticated, null if not authenticated or on error
Safe to call fromAny Server Component, layout.js, page.js, or route.js
Session sourceReads from HTTP cookies via next/headers — no client-side state needed

​
Usage in the Root Layout

A common pattern in Monza Motors is to call getUser() inside the root layout.js and pass the result into AuthProvider as initialUser. This pre-populates the client-side auth context on the first render, avoiding a loading flash or redundant client-side session fetch. 
import { getUser } from '@/services/auth/auth.server';
import { AuthProvider } from '@/context/AuthContext';

export default async function RootLayout({ children }) {
  const user = await getUser(); // server-side — reads from cookies

  return (
    <html lang="en">
      <body>
        <AuthProvider initialUser={user}>
          {children}
        </AuthProvider>
      </body>
    </html>
  );
}
Because getUser() runs on the server before the page is streamed to the browser, AuthProvider receives the correct user state synchronously. Client components that consume AuthProvider will always have access to the initial user without waiting for an additional round-trip.
signIn, signOut, and registerService can only be called from 'use client' components or browser event handlers. They rely on createBrowserClient from @supabase/ssr, which uses browser-side APIs (localStorage, document.cookie) that do not exist in the Node.js server runtime. Calling any of these functions inside a Server Component, layout.js, or an API route handler will throw a runtime error.

Build docs developers (and LLMs) love

Get started for freeTalk to us