Auth

The template includes sign-in, sign-up and forgot-password screens, with placeholder handlers and a fixed demo user. They let you work on the app before connecting authentication; they do not verify credentials or protect your pages.

To connect authentication, choose your auth provider or library and follow its Next.js setup. You will connect the form handlers, return the real session and add access checks for private pages and data.

Connect the auth forms

The screens pass submitted values to handlers inside IMPLEMENT_START and IMPLEMENT_END comments. Replace the placeholder work in these blocks with your provider calls:

Use a browser-safe provider SDK in these handlers, or call a server function for operations that require private credentials.

Remove the placeholder timers and credential logging. Keep the loading and error feedback, and show success only after the provider confirms the operation. A provider may return a failed result instead of throwing an error, so handle that result before continuing.

The sign-in and sign-up handlers currently navigate to appConfig.auth.authenticatedEntryPath, configured in src/configs/app.config.ts. Navigate into the app once a session is established; if sign-up requires verification first, follow that flow instead. Complete the password-reset flow using your provider's reset-link and new-password handling.

Return the real session

A successful sign-in establishes a session that later requests use to identify the person. Replace the fixed result in getUserSession() in src/actions/session.ts with your provider's server-side session lookup.

Map the result to the Session type in src/contexts/Session/types.ts. Put profile fields such as id, name, email and image under user, and roles under user.authority if used. Set expires to the expiry reported by your provider, as an ISO date string.

When no valid session exists, return null and change the function's return type to Promise<Session | null>. The template's session provider already accepts null.

The root layout supplies this result to SessionProvider. Client components can read it with:

const { session } = useSession()

Import useSession from @/contexts/Session. It reads the session supplied to the UI; your provider remains responsible for creating and validating that session. Follow the provider's session-update flow after sign-in and sign-out so the displayed user stays current.

Connect sign-out

The user menu's handler is in src/components/layouts/post-login-layout.tsx, inside the SIGN_OUT block. It currently calls handleServerSignOut() from src/actions/auth.ts and then navigates to /sign-in.

If your provider signs out on the server, replace the placeholder inside that function's SIGN_OUT_SERVER block. If it uses a client SDK, call that from the menu handler. End the session before redirecting; navigating to the sign-in screen alone does not sign someone out.

Protect pages and data

The (protected-pages) group applies the app layout. Its name does not enforce authentication. Add your provider's Next.js route protection so signed-out visitors are sent to sign-in when opening private pages.

Check the session and required permissions in the server functions and API handlers that read or change private data too. Hiding a page or menu link does not prevent a direct request to its backend.

Some integrations use src/proxy.ts for early redirects. Follow your provider's matcher and callback requirements, and keep the data-access checks alongside it. The Next.js authentication guide explains where these checks belong.

Roles and permissions

If your app uses roles, map the signed-in user's roles to user.authority. Routes can declare an authority list in src/configs/routes.config.ts, but the template does not enforce that list automatically.

Use your server-side access checks to decide whether the current user may open a page or perform an operation. Treat menu visibility as a separate UI decision.