mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-22 06:56:35 +00:00
Maurice
9814480a96
middleware/auth.ts exported seven things. Two of them — extractToken and verifyJwtAndLoadUser — are the canonical session check every auth surface goes through. The other five (authenticate, requireCookieAuth, optionalAuth, adminOnly, demoUploadBlock) are Express middlewares with no production caller left; the guards in nest/auth replaced them and only comments still mention them. The two live functions move to nest/auth/jwt-verify.ts and the file goes, along with middleware/validate.ts (nothing but its own test imported it) and middleware/idempotency.ts (its only caller was `authenticate`, and IdempotencyInterceptor has replaced it). AuthRequest and OptionalAuthRequest go with them — src/typings/express.d.ts is what types req.user now. Eight importers repoint: the three guards, auth/files/plugins-proxy services, platform.routes and the global MFA policy. Two deliberate departures from the plan for this package. JWT_SECRET does not move to app-config. It is not an env value: it is generated into data/.jwt_secret, and the admin panel rotates it at runtime through updateJwtSecret. `export let` is precisely what makes a rotation take effect in-process — a registerAs token would freeze the boot value and silently break rotation. The verify also keeps reading the db singleton rather than DatabaseService. That change is not a one-line swap: it gives the three guards a constructor dependency, which means registering them as providers everywhere they are used. Measured: 38 directories use those guards and 21 of them do not import AuthModule, on top of 34 e2e tests that each build a container around a single domain module. That is its own PR, not a rider on one that deletes dead files. tests/unit/middleware/auth.test.ts covered real behaviour, so it is not simply deleted. Its extractToken cases and the five verify cases it drove through `authenticate` come back as tests/unit/nest/auth/jwt-verify.test.ts, now hitting verifyJwtAndLoadUser directly. Four cases are new: the password_version gate — the whole reason this function exists — had no direct coverage at all. Its three adminOnly cases are dropped because AdminGuard, their successor, is covered by three e2e suites.
27 lines
1.1 KiB
TypeScript
27 lines
1.1 KiB
TypeScript
import { CanActivate, ExecutionContext, HttpException, Injectable } from '@nestjs/common';
|
|
import type { Request } from 'express';
|
|
import { verifyJwtAndLoadUser } from './jwt-verify';
|
|
|
|
/**
|
|
* Mirrors the legacy `requireCookieAuth` middleware: accepts ONLY the httpOnly
|
|
* trek_session cookie (never a Bearer token), so CSRF-sensitive state-changing
|
|
* OAuth endpoints (consent submit, client/session mutations) can't be driven by
|
|
* a leaked Bearer. Error bodies + codes match the legacy 401 shapes exactly.
|
|
*/
|
|
@Injectable()
|
|
export class CookieAuthGuard implements CanActivate {
|
|
canActivate(context: ExecutionContext): boolean {
|
|
const req = context.switchToHttp().getRequest<Request & { cookies?: Record<string, string> }>();
|
|
const cookieToken = req.cookies?.trek_session;
|
|
if (!cookieToken) {
|
|
throw new HttpException({ error: 'Cookie session required for this endpoint', code: 'COOKIE_AUTH_REQUIRED' }, 401);
|
|
}
|
|
const user = verifyJwtAndLoadUser(cookieToken);
|
|
if (!user) {
|
|
throw new HttpException({ error: 'Invalid or expired session', code: 'AUTH_REQUIRED' }, 401);
|
|
}
|
|
req.user = user;
|
|
return true;
|
|
}
|
|
}
|