PassportJS、NestJS：AuthGuard('jwt') 的 canActivate 方法

如何解决PassportJS、NestJS：AuthGuard('jwt') 的 canActivate 方法

有人知道我在哪里可以看到 AuthGuard('jwt') 中 canActivate 方法的完整代码吗？我意识到 canActivate 方法通过使用 console.log() 调用 JwtStrategy 验证方法，如下所示：

fitz.pixmap(doc,51)

如果我使用原来的 canActivate 方法，console.log 会被调用。我认为 JwtStrategy 是一个中间件，所以只要有请求就会调用 validate 方法。但是，当我尝试覆盖 canActivate 方法以添加授权时，不会调用 JwtStrategy 验证方法中的 console.log：

// jwt.strategy.ts

@Injectable()
export class JwtStrategy extends PassportStrategy(Strategy) {
  constructor(
    private readonly configService: ConfigService,private readonly useRSService: UseRSService,) {
    super({
      jwtFromrequest: ExtractJwt.fromAuthHeaderAsBearerToken(),ignoreExpiration: true,secretorKey: configService.get<string>('JWT_SECRET'),});
  }

  async validate(payload: any) {
    try {
      const user = await this.useRSService.getUserById(payload.id);
      // console.log is here
      console.log(user);
      return user;
    } catch (e) {
      console.log(e);
      return null;
    }
  }
}

然后我试图找到AuthGuard（'jwt'）的原始代码以了解其逻辑，但我无法找到。任何帮助将不胜感激，谢谢！

解决方法

好的，所以这将是一次非常有趣的深入探讨。系好安全带。

Middleware 作为 express 方法在 NestJS 中仍然存在；也就是说，这不是 Express 中间件意义上的 noraml 中间件。正如您所提到的，AuthGuard()#canActivate() 最终会调用相应的 PassportStrategy。这些策略特别在第 40-41 行获得 registered here，其中 passport.use() 被调用。这将注册用于 validate 的通行证策略类的 passport.veryfiy() 方法。大多数底层逻辑非常抽象，阅读时可能会丢失上下文，因此请花点时间了解类、mixin（返回类的函数）和继承的概念。

Line 51 of AuthGuard 是 passportfn 最初创建的地方，在这个 passportFn passport.authenticate 被调用（它在其引擎盖下调用 passport.verify）（通读Passport 的代码更加混乱，所以我会让你在需要时运行它）。

如果您想向 canActivate() 方法添加一些额外的逻辑，您可以最终调用 super.canActivate(context) 来调用最终调用 canActivate() 的原始 passport.authetnicate() 方法，因此<Strategy>#validate。这可能看起来像

@Injectable()
export class CustomAuthGuard extends AuthGuard('jwt') {

  async canActivate(context: ExecutionContext): Promise<boolean> {
    // custom logic can go here
    const parentCanActivate = (await super.canActivate(context)) as boolean; // this is neccssary due to possibly returning `boolean | Promise<boolean> | Observable<boolean>
    // custom logic goes here too
    return parentCanActivate && customCondition;
  }
}