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.
20 lines
832 B
TypeScript
20 lines
832 B
TypeScript
import { CanActivate, ExecutionContext, Injectable } from '@nestjs/common';
|
|
import type { Request } from 'express';
|
|
import { extractToken, verifyJwtAndLoadUser } from './jwt-verify';
|
|
|
|
/**
|
|
* Mirrors the legacy `optionalAuth` middleware: populates req.user with the
|
|
* loaded user when a valid token is present, otherwise leaves it null — and
|
|
* always allows the request through (never 401). Used for endpoints whose
|
|
* response varies by auth state but don't require it (e.g. /app-config).
|
|
*/
|
|
@Injectable()
|
|
export class OptionalJwtGuard implements CanActivate {
|
|
canActivate(context: ExecutionContext): boolean {
|
|
const req = context.switchToHttp().getRequest<Request>();
|
|
const token = extractToken(req);
|
|
(req as { user: unknown }).user = (token ? verifyJwtAndLoadUser(token) : null) || null;
|
|
return true;
|
|
}
|
|
}
|