Guards bestemmer, om en anmodning tillades at fortsætte til routehandleren — de er NestJS's dedikerede mekanisme for autorisering (og ofte autentificeringstjek). En guard returnerer true for at tillade anmodningen eller false/kaster for at blokere den.
@Injectable()
export class AuthGuard implements CanActivate {
canActivate(context: ExecutionContext): boolean {
const request = context.switchToHttp().getRequest();
return !!request.headers.authorization; // true = allow, false = block (403)
}
}
En guard implementerer canActivate(), som returnerer en boolean (eller Promise/Observable af en). At returnere false blokerer anmodningen med en 403; du kan også kaste en specifik undtagelse (f.eks. UnauthorizedException).
@UseGuards(AuthGuard) // on a single route
@Get("profile")
getProfile() {}
@UseGuards(AuthGuard) // on a whole controller (all routes)
@Controller("admin")
export class AdminController {}
app.useGlobalGuards(new AuthGuard()); // globally (all routes)
Guards kan anvendes på metode-, controller- eller globalt niveau.
@Injectable()
export class JwtAuthGuard implements CanActivate {
constructor(private jwtService: JwtService) {}
async canActivate(context: ExecutionContext): Promise<boolean> {
const request = context.switchToHttp().getRequest();
const token = request.headers.authorization?.split(" ")[1];
if (!token) throw new UnauthorizedException();
try {
request.user = await this.jwtService.verifyAsync(token); // attach the user
return true;
} catch {
throw new UnauthorizedException("Invalid token");
}
}
}
// a @Roles decorator stores required roles as metadata
@Roles("admin")
@Get("users")
listUsers() {}
// the RolesGuard reads the metadata and checks the user's roles
@Injectable()
export class RolesGuard implements CanActivate {
constructor(private reflector: Reflector) {}
canActivate(ctx: ExecutionContext): boolean {
const roles = this.reflector.get<string[]>("roles", ctx.getHandler());
const { user } = ctx.switchToHttp().getRequest();
return roles.some(role => user.roles?.includes(role)); // allow if the user has a required role
}
}
At kombinere en @Roles()-dekorator (metadata) med en guard, der læser den (via Reflector), er standardmønstret for rollebaseret adgangskontrol.
The ExecutionContext gives guards rich info (the handler, class, request) — more
than plain middleware — which is why guards (not middleware) are the right place
for authorization decisions.
Guards er den dedikerede, idiomatiske NestJS-mekanisme for autorisering — kontrol af, hvilke anmodninger der får lov at nå handlere baseret på autentificering og tilladelser.
At forstå dem er afgørende, fordi stort set hver rigtig applikation skal beskytte ruter (kræve login, kontrollere roller/tilladelser), og guards er det rigtige værktøj til det (langt renere end at proppe autentificeringslogik ind i middleware eller hver handler).
Standardmønstrene — en JWT/auth-guard, der verificerer legitimationsoplysninger og vedhæfter brugeren til anmodningen, og rollebaserede guards, der kombinerer en @Roles()-dekorator med en Reflector-læsende guard til RBAC — er grundlæggende for at sikre NestJS API'er.
Guards' adgang til den rige ExecutionContext (med viden om targethandler, klasse og anmodning) er præcis det, der gør dem egnede til autorisationsbeslutninger, som middleware ikke kan træffe rent.
At vide, hvordan man skriver, anvender (metode/controller/global) og kombinerer guards med metadata-dekoratorer, er kernekompetence for at bygge sikre NestJS-applikationer og er et hyppigt, arkitektonisk vigtig emne i frameworket.
Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér