Guard interface (canActivate) in NestJS - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the purpose of the canActivate method in a NestJS guard?

The canActivate method decides if a request can proceed to the route handler. It returns true to allow or false to block access.

beginner

How do you implement a guard using the canActivate method in NestJS?

Create a class that implements the <code>CanActivate</code> interface and define the <code>canActivate(context: ExecutionContext)</code> method to return a boolean, Promise<boolean>, or Observable<boolean>.

intermediate

What does the ExecutionContext parameter provide inside canActivate?

It gives access to details about the current request, like the HTTP request object, handler, and class, so you can check user info or request data.

intermediate

Can canActivate return asynchronous results? How?

Yes, it can return a Promise<boolean> or an Observable<boolean>. NestJS will wait for the result before allowing or blocking access.

beginner

Where do you apply a guard that uses canActivate in a NestJS app?

You can apply it at the controller level, route handler level, or globally to protect routes by adding the guard with decorators or in the app module.

What should the canActivate method return to allow access to a route?

A false

B null

C true

D undefined

Returning true means the guard allows the request to proceed.

Which interface must a guard class implement to use canActivate?

A PipeTransform

B CanDeactivate

C OnModuleInit

D CanActivate

The CanActivate interface requires the canActivate method.

What does the ExecutionContext NOT provide inside canActivate?

A Access to the database connection

B Access to the route handler

C Access to the HTTP request

D Access to the controller class

ExecutionContext does not provide direct access to the database connection.

Can canActivate return an Observable<boolean>?

A Yes

B No

C Only if wrapped in a Promise

D Only if synchronous

NestJS supports returning an Observable from canActivate.

Where can you apply a guard in a NestJS application?

A Only on route handlers

B On controllers, route handlers, or globally

C Only globally

D Only in middleware

Guards can be applied at multiple levels: controller, route handler, or globally.

Explain how the canActivate method works in a NestJS guard and what it controls.

Think about how guards decide if a user can enter a page.

Describe how you would create and apply a simple guard using canActivate in a NestJS app.

Imagine you want to block or allow users based on a rule.

Practice

1. What is the main purpose of the canActivate method in a NestJS guard?

easy

A. To format the response data

B. To handle database connections

C. To decide if a request should be allowed or denied access

D. To log user activity

Solution

1. Step 1: Understand the role of guards in NestJS

   Guards are used to control access to routes by allowing or denying requests.

2. Step 2: Identify the function of canActivate

   The canActivate method returns true or false to allow or deny access.

3. Final Answer:

   To decide if a request should be allowed or denied access -> Option C

4. Quick Check:

   Guard access control = canActivate returns true/false [OK]

Hint: Remember: canActivate returns true to allow access [OK]

Common Mistakes:

• Confusing canActivate with response formatting
• Thinking canActivate handles database logic
• Assuming canActivate logs user actions

2. Which of the following is the correct syntax to implement a guard class with canActivate in NestJS?

easy

A. class MyGuard { canActivate(context) { return true; } }

B. function MyGuard() { canActivate() { return true; } }

C. const MyGuard = () => { canActivate() { return true; } }

D. class MyGuard implements CanActivate { canActivate(context: ExecutionContext): boolean { return true; } }

Solution

1. Step 1: Recognize the NestJS guard pattern

   Guards are classes that implement the CanActivate interface.

2. Step 2: Check the method signature and class syntax

   The method must be named canActivate and accept an ExecutionContext parameter, returning a boolean.

3. Final Answer:

   class MyGuard implements CanActivate { canActivate(context: ExecutionContext): boolean { return true; } } -> Option D

4. Quick Check:

   Guard class implements CanActivate with canActivate method [OK]

Hint: Use class with implements CanActivate and proper method signature [OK]

Common Mistakes:

• Using function instead of class
• Missing implements CanActivate
• Incorrect method parameters or return type

3. Given this guard code, what will be the result when a request is made?

class AlwaysDenyGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    return false;
  }
}

medium

A. The request is denied access

B. The request is allowed to proceed

C. A runtime error occurs

D. The guard is ignored and request proceeds

Solution

1. Step 1: Analyze the canActivate return value

   The method always returns false, meaning access is denied.

2. Step 2: Understand guard effect on request

   When canActivate returns false, NestJS blocks the request from continuing.

3. Final Answer:

   The request is denied access -> Option A

4. Quick Check:

   canActivate false = deny request [OK]

Hint: False return in canActivate means deny access [OK]

Common Mistakes:

• Assuming false allows access
• Thinking guard causes error on false
• Believing guard is skipped if false

4. Identify the error in this guard implementation:

class MyGuard implements CanActivate {
  canActivate() {
    return true;
  }
}

medium

A. Incorrect return type for canActivate

B. Missing parameter in canActivate method

C. Class does not implement CanActivate interface

D. canActivate method should be async

Solution

1. Step 1: Check method signature requirements

   The canActivate method must accept a parameter of type ExecutionContext.

2. Step 2: Compare with given code

   The method has no parameters, which breaks the interface contract.

3. Final Answer:

   Missing parameter in canActivate method -> Option B

4. Quick Check:

   canActivate needs ExecutionContext parameter [OK]

Hint: canActivate always needs ExecutionContext parameter [OK]

Common Mistakes:

• Omitting method parameters
• Assuming async is required
• Ignoring interface implementation rules

5. You want to create a guard that only allows access if the user role is 'admin'. Which of these canActivate implementations correctly checks the role from the request object?

hard

A. canActivate(context: ExecutionContext): boolean {
const request = context.switchToHttp().getRequest();
return request.user?.role === 'admin';
}

B. canActivate(context: ExecutionContext): boolean {
const user = context.getUser();
return user.role === 'admin';
}

C. canActivate(context: ExecutionContext): boolean {
const request = context.getRequest();
return request.user.role === 'admin';
}

D. canActivate(context: ExecutionContext): boolean {
const req = context.switchToHttp().getRequest();
return req.user.role == 'admin';
}

Solution

1. Step 1: Access the HTTP request correctly

   Use context.switchToHttp().getRequest() to get the request object.

2. Step 2: Safely check the user role

   Use optional chaining request.user?.role to avoid errors if user is undefined.

3. Final Answer:

   canActivate(context: ExecutionContext): boolean { const request = context.switchToHttp().getRequest(); return request.user?.role === 'admin'; } -> Option A

4. Quick Check:

   Use switchToHttp and optional chaining for safe role check [OK]

Hint: Use switchToHttp().getRequest() and optional chaining for safety [OK]

Common Mistakes:

• Using context.getUser() which does not exist
• Calling context.getRequest() directly without switchToHttp()
• Not using optional chaining causing runtime errors