Route Guards

Configure guardedPaths and guestPaths to have the framework automatically inject global route guard middleware, handling login interception and logged-in-user redirects.

Configuration

// nuxt.config.ts
swiftConfig: {
  auth: {
    // Paths that require authentication (prefix-matched)
    guardedPaths: ['/mine', '/dashboard', '/settings'],

    // Paths inaccessible to logged-in users (e.g. login page, register page)
    // Authenticated users visiting these paths are redirected to the home page
    guestPaths: ['/login', '/register'],
  }
}

Guard Behavior

Path type	Unauthenticated access	Authenticated access
Paths in `guardedPaths`	Redirect to `/login?redirect=<original>`	Normal access
Paths in `guestPaths`	Normal access	Redirect to `/` (home page)
All other paths	Normal access	Normal access

Path Matching

Prefix matching is used: guardedPaths: ['/mine'] matches /mine, /mine/favorites, /mine/settings, and all other paths starting with /mine.

The guard stores the original path in the ?redirect= query parameter. After a successful login, useLoginBy() automatically reads it and navigates back to the page the user was trying to reach.

Custom Guard Logic

For more complex guard logic (e.g. role-based access control), create custom middleware in app/middleware/:

// app/middleware/auth.global.ts
export default defineNuxtRouteMiddleware(async (to) => {
  const userStore = useUserStore()

  // Custom: admin pages require the admin role
  if (to.path.startsWith('/admin')) {
    const loggedIn = await useLoginCheck()
    if (!loggedIn) return navigateTo('/login')
    if (!userStore.info?.isAdmin) return navigateTo('/')
  }
})

Security behavior

framework ships two auth-related security behaviors; both apply by default with no extra configuration:

Rejection of URL-injected channel codes

The systemStore.initCode() action (invoked by framework plugins during initialization) detects channel codes injected via URL query (?code=...) on ?switch=1 paths and rejects them, preventing malicious share links from hijacking attribution. Channel-code switches on legitimate in-app paths still go through.

Logout revokes the server-side session, then clears local state

The framework logout flow (userStore.logout()) first revokes the current session via POST /login/logout — failures are swallowed and never block the logout (network errors or a backend without this endpoint still get full local cleanup, zero adaptation cost) — then synchronously clears:

The channel-code cookie (Set-Cookie: code=; Max-Age=0)
IDB decryption cache (e.g. blob URLs cached by useDecryptedAsset)
Login-credential localStorage (so the next user does not pick up residue from the previous one)

This prevents post-logout state from leaking into the next session or user, and guarantees the old token is invalidated server-side immediately — "the user has logged out" is a real security boundary again (per OWASP session-management guidance).