Guards bestemmer om en forespørsel er tillatt å fortsette til route-handleren — de er NestJS's dedikerte mekanisme for autorisasjon (og ofte autentiseringskontroller). En guard returnerer true for å tillate forespørselen eller false/kaster et unntak for å blokkere 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 av en). Returnering av false blokkerer forespørselen med en 403; du kan også kaste et spesifikt unntak (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 brukes på metode-, controller- eller globalt nivå.
@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
}
}
Å kombinere en @Roles()-dekorator (metadata) med en guard som leser den (via Reflector) er standardmønsteret for rollebasert tilgangskontroll.
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 dedikerte, idiomatiske NestJS-mekanismen for autorisasjon — som kontrollerer hvilke forespørsler som har tillatelse å nå handlere basert på autentisering og tillatelser.
Å forstå dem er essensielt fordi praktisk talt hver virkelighets applikasjon må beskytte ruter (kreve innlogging, sjekke roller/tillatelser), og guards er det korrekte verktøyet for dette (langt renere enn å fylle autorisasjonslogikk inn i middleware eller hver handler).
Standardmønstrene — en JWT/auth guard som verifiserer legitimasjon og fester brukeren til forespørselen, og rollebaserte guards som kombinerer en @Roles()-dekorator med en Reflector-lesende guard for RBAC — er grunnleggende for å sikre NestJS API-er.
Guards' tilgang til den rike ExecutionContext (å kjenne målhandleren, klassen og forespørselen) er nettopp det som gjør dem egnet til autorisasjonsbeslutninger som middleware ikke kan gjøre rent.
Å vite hvordan du skriver, bruker (metode/controller/globalt) og kombinerer guards med metadata-dekoratorer er kjernekunnskap for å bygge sikre NestJS-applikasjoner og et hyppig, arkitektonisk viktig emne i rammeverket.