From Harness Web
Auth.js v5 authentication conventions — encrypted sessions, env-var-only secrets, server vs client session access, edge middleware route protection, and provider credential inference. Use when adding or reviewing a login flow, OAuth, or session handling.
How this skill is triggered — by the user, by Claude, or both
Slash command
/harness-web:addon-authjsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Auth.js v5 handles authentication. Sessions are encrypted with `AUTH_SECRET`.
Auth.js v5 handles authentication. Sessions are encrypted with AUTH_SECRET.
Provider credentials are read from environment variables — never from source code.
Security invariants (non-negotiable):
session.user, token, or any object that may contain credentials,
email, or session identifiers. Tokens in logs are a breach.AUTH_SECRET, AUTH_GITHUB_SECRET, etc.) must be environment
variables. They must not appear in source files, .env.example with real values,
or commit history.AUTH_SECRET must be generated with npx auth secret — do not hand-write it.Session access:
const session = await auth() — returns the session or
null; access is server-side only and safe.<SessionProvider> and call useSession().
The client session exposes only what you explicitly include in the JWT/session
callback — no raw tokens.Route protection:
middleware.ts at the project root) to protect routes
at the edge. Do not add manual if (!session) redirect() checks in every page.authorized callback in auth.config.ts to declare which paths
require authentication.Environment variable naming (provider inference):
Auth.js automatically infers provider credentials if named AUTH_<PROVIDER>_ID
and AUTH_<PROVIDER>_SECRET. This means no manual clientId/clientSecret
in the provider array for official providers.
AUTH_GITHUB_ID=...
AUTH_GITHUB_SECRET=...
AUTH_GOOGLE_ID=...
AUTH_GOOGLE_SECRET=...
npx claudepluginhub camilool8/harness-engineering-templates --plugin harness-webGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Resolves in-progress git merge or rebase conflicts by analyzing history, understanding intent, and preserving both changes where possible. Runs automated checks after resolution.