인프런 커뮤니티 질문&답변

김동민님의 프로필 이미지

작성한 질문수

[코드팩토리] [초급] NestJS REST API 백엔드 완전 정복 마스터 클래스 - NestJS Core

BearerTokenGuard 구현해보기

auth/token/access, auth/token/refresh 엔드포인트에 대한 Guard 적용

해결된 질문

24.09.07 21:19 작성

·

29

0

현재 듣고 있는 강의 부분은 Guard chapter에서 basic, bearer guard를 적용하는 부분입니다.

@Injectable()
export class BearerTokenGuard implements CanActivate {
  constructor(
    private readonly authService: AuthService,
    private readonly usersService: UsersService,
  ) {}

  async canActivate(context: ExecutionContext): Promise<boolean> {
    const req = context.switchToHttp().getRequest();

    const rawToken = req.headers['authorization'];

    if (!rawToken) {
      throw new UnauthorizedException('토큰이 없음');
    }

    const token = this.authService.extractTokenFromHeader(rawToken, true);

    const result = await this.authService.verifyToken(token); // payload 반환

    /**
     * req 객체에 넣을 정보
     * 1) 사용자 정보 - user 객체 자체
     * 2) token - token
     * 3) tokenType - access | refresh
     */
    const user = await this.usersService.getUserByEmail(result.email);

    req.user = user;
    req.token = token;
    req.tokenType = result.type;

    return true;
  }
}

제 개인적인 생각으로는 적어도 제목에 적힌 두 엔드포인트에 대해서는 현재의 BearerTokenGuard를 적용하는 것이 굳이 라는 생각이 듭니다. refreshToken을 이용하여 새로운 토큰을 발급받는 역할을 하는 두 엔드포인트에 대해 다른 줄은 다 문제가 크게 없다고 생각하지만 req.user = user;로 굳이 요청에 user 객체를 붙이는 것은 굳이라는 생각이 듭니다. 제 낮은 식견으로는 위 두 엔드포인트에 대한 guard는 또 따로 만들어야 한다고 생각이 드는데 강사님 생각이 궁금합니다.

답변 1

1

코드팩토리님의 프로필 이미지
코드팩토리
지식공유자

2024. 09. 08. 16:44

안녕하세요!

아래 코드 RefreshTokenGuard 적용된 부분 말씀하시는거 맞을까요!?

https://github.com/codefactory-co/nestjs-lv1/blob/4f358495060a8788d1d176b998fd26f609e5a599/src/auth/auth.controller.ts#L14-L44

충분히 유효한 말씀이라고 생각합니다.

낮은 식견 절대 아닙니다 이런 "생각"을 하고 있다는 것 자체가 매우 좋은 현상입니다. 꾸준히 의심을 갖고 생각하고 개선하려고 하는 노력이 좋은 개발자를 만듭니다.

일단 제 국룰 답변은 "정답은 없다"입니다. 제가 이런식을 말씀드리는 이유는 저희는 벌써 이 문제를 바라보고있는 관점이 다릅니다.

저는 "어차피 있는 BearerToken을 그대로 활용하면 편하고 굳이 또 다른 Guard를 관리할 필요가 없지 않나?"가 포인트라고 볼 수 있습니다. (진짜 정확히 말씀드리면 강의에서의 "의도"라고 말씀드릴 수 있습니다. 강의 프로젝트는 "제가 프로젝트를 구현한다고" 생각하고 구현하지 않습니다. "많은 지식을 컴팩트하게 전달해드리기위해" 억지로라도 다양한 요소를 끼워넣어 기획합니다)

수강생분은 "req.user 어차피 안쓰는데 굳이 왜넣음?"이 포인트입니다. 이게 포인트가 될 경우 제가 반박 할 수가 없습니다. 그리고 req.user를 붙이지 않는 새로운 Guard를 생성하는 해결법은 말씀하신 포인트에 아주 적절히 잘 대응하신 부분이라고 말씀 드릴 수 있습니다.

혹시 애매한 답변처럼 느껴지셨다면 댓글로 다시한번 질문 주시면 추가로 답변 드리도록 하겠습니다!

감사합니다!