JWT Strategies & RBAC — Series 3

Preview — 3 of 10 questions

How does fromExtractors behave?

javascript

super({
  jwtFromRequest: ExtractJwt.fromExtractors([
    (req: Request) => req?.cookies?.access_token ?? null,
    ExtractJwt.fromAuthHeaderAsBearerToken(),
  ]),
  secretOrKey: config.getOrThrow('JWT_SECRET'),
});

AIt requires the token to be present in every listed source

BIt concatenates the values from all sources into one token

CIt tries each extractor in order and uses the first non-null result — so a browser client can authenticate with an HttpOnly cookie while a mobile client or a service uses the Authorization header, both served by one strategy

DIt picks a source at random for load distribution

How do the two guards combine?

javascript

@Module({ providers: [{ provide: APP_GUARD, useClass: JwtAuthGuard }] })
export class AppModule {}

@Roles('admin')
@UseGuards(RolesGuard)
@Delete(':id') remove() {}

ABoth run — global guards first, then route-level ones — so JwtAuthGuard authenticates and populates req.user, and RolesGuard then reads that user; both must pass, and the ordering is what makes the role check possible at all

BThe route-level guard replaces the global one for this handler

COnly the global guard runs, since it is registered at a higher level

DThey run in parallel, so RolesGuard may not see req.user

What design holds up?

javascript

A new account must confirm its email before it can act.

ASend the user's id in the link and mark the account verified when it is visited

BBlock login entirely until verification, and re-send the same link on request

CInclude the email address in the link so the endpoint can match it

DEmail a link containing a high-entropy, single-use, short-lived token stored hashed against the account; visiting it marks the account verified and consumes the token — and the account's capabilities, not its ability to log in, are what verification gates

Answer all 10 questions (7 more), see explanations for every answer, and track your score.