Проблема с главой Аутентификация и 19-аутентичным примером - PullRequest
Новая
       6

Проблема с главой Аутентификация и 19-аутентичным примером

1 голос
/ 31 марта 2019

Я скачал образец 19-auth и добавил к нему некоторый отладочный код console.log, затем обнаружил некоторые проблемы.

Код в JwtAuthGuard никогда не выполняется: «2222222» не выводился на консоль вкод ниже: 

canActivate(context: ExecutionContext) {
console.log('22222222222');
// add your custom authentication logic here
// for example, call super.logIn(request) to establish a session.
return super.canActivate(context);
}

Когда я изменил защиту на JwtAuthGuard в AuthController: 

@get('data')
@UseGuards(JwtAuthGuard)
findAll(@Req() req) {
return req.user;
// this route is restricted by AuthGuard
// JWT strategy
}

был вызван код в JwtAuthGuard, но в функции canActivate я не могуполучить информацию о пользователе из запроса.а функция canActivate была вызвана до JwtStrategy?

Может кто-нибудь объяснить, как выполняется код для модуля auth и как получить информацию о пользователе в JwtAuthGuard?

вставить последний код ижурнал консоли здесь:

JwtStrategy 

/**
   * jwt passport 调用validate方法来判断是否授权用户进行接口调用
   * @param payload
   */
  async validate(payload: AuthPayload) {
    Logger.log(`payload is ${JSON.stringify(payload)}`, 'JwtStrategy');
    const user = await this.authService.validateUser(payload.id);
    if (!user) {
      throw new UnauthorizedException('不存在的用户信息');
    }
    return user;
  }

JwtAuthGuard 

canActivate(context: ExecutionContext) {
    // add your custom authentication logic here
    // for example, call super.logIn(request) to establish a session.
    // this.accessPriv = this.reflector.get<string>('accessPriv', context.getHandler());
    console.log('canActivate executed 111111111111111111');
    return super.canActivate(context);
  }

и журнал консоли, как показано ниже: 

canActivate executed 111111111111111111

[Nest] 14080   - 2019-04-01 11:19   [JwtStrategy] payload is {"userName":"fanliang","id":"1","iat":1553772641,"exp":1554377441} +2286ms
it seems that the canActivate() function of JwtAuthGuard executed before the validate() function of JwtStrategy, but the user info was attached to the request after JwtStrategy validate().

я хочу получить информацию о пользователе из запроса в canActivate () пользовательского AuthGuard, такого как JwtAuthGuard

Ответы [ 2 ]

0 голосов
/ 29 апреля 2019

У меня есть какое-то решение, которое работает для меня.Вызов super.canActivate до моей собственной логики.
похоже на то, что запускается req.user.
Пример: 

import { ExecutionContext, Injectable } from "@nestjs/common";
import { AuthGuard } from "@nestjs/passport";
import { Request } from "express";

@Injectable()
export class AuthGuardWithAllowSentry extends AuthGuard("jwt") {
  public async canActivate(context: ExecutionContext) {
    // that code will call the passport jwt
    const origCanActivate = await super.canActivate(context);
    // now we have request.user!


    const http = context.switchToHttp();
    const request = http.getRequest<Request>();

    console.log(request.user)

    if (request.header("X-Sentry-Token") === "blablabla") {
      if (request.method === "GET" && request.path.endsWith(".map")) {
        return true;
      }
    }

    // some random logic
    return request.user.roles.includes("admin")
  }
}

для меня это больше похоже на обходной путь, чемреальная вещь.

0 голосов
/ 31 марта 2019

Я согласен, что образец 19-auth немного запутанный, чтобы следовать. В основном это связано с тем, что он включает JWTAuthGuard (в качестве справочного материала для создания пользовательских охранников), но фактически никогда не используется. Вместо этого первоначальное использование обычного AuthGuard уже настроено для обеспечения функциональности JWT. Однако, оба охранника используют JWTStrategy. Если вы хотите лучше понять это, попробуйте обновить AuthController: 

  @Get('data')
  @UseGuards(AuthGuard())
  findAll() {
    // this route is restricted by AuthGuard
    // JWT strategy
    return {
      message: 'Successfully passed AuthGuard',
    };
  }

  @Get('custom-jwt')
  @UseGuards(new JwtAuthGuard())
  // this route is restricted by JWTAuthGuard custom
  // JWT strategy
  customJwt() {
    return {
      message: 'Successfully passed JWTAuthGuard',
    };
  }

Важной частью является то, что для того, чтобы обойти любого из охранников, вы должны отправить запрос с правильно установленным заголовком авторизации на токен, который возвращается из конечной точки token.

Например: Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6InRlc3RAZW1haWwuY29tIiwiaWF0IjoxNTU0MDUyNDczLCJleHAiOjE1NTQwNTYwNzN9.3Q8_FC-qFXk1F4KmMrHVSmmNGPAyHdt2myr5c18_E-U

Я считаю, что проще всего использовать такой инструмент, как Postman или Insomnia, для построения запросов, установки заголовков и т. Д., Но вы также можете использовать CURL. После того, как вы установили заголовок Authorization с действительным токеном, вы сможете поразить обе из защищенных конечных точек. Если вы введете console.log в стратегию JWTS, вы увидите, что оба охранника в конечном итоге используют метод validate для правильного извлечения пользователя.

...