해결된 질문
작성
·
72
1
현재 듣고 있는 강의 부분은 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
안녕하세요!
아래 코드 RefreshTokenGuard 적용된 부분 말씀하시는거 맞을까요!?
충분히 유효한 말씀이라고 생각합니다.
낮은 식견 절대 아닙니다 이런 "생각"을 하고 있다는 것 자체가 매우 좋은 현상입니다. 꾸준히 의심을 갖고 생각하고 개선하려고 하는 노력이 좋은 개발자를 만듭니다.
일단 제 국룰 답변은 "정답은 없다"입니다. 제가 이런식을 말씀드리는 이유는 저희는 벌써 이 문제를 바라보고있는 관점이 다릅니다.
저는 "어차피 있는 BearerToken을 그대로 활용하면 편하고 굳이 또 다른 Guard를 관리할 필요가 없지 않나?"가 포인트라고 볼 수 있습니다. (진짜 정확히 말씀드리면 강의에서의 "의도"라고 말씀드릴 수 있습니다. 강의 프로젝트는 "제가 프로젝트를 구현한다고" 생각하고 구현하지 않습니다. "많은 지식을 컴팩트하게 전달해드리기위해" 억지로라도 다양한 요소를 끼워넣어 기획합니다)
수강생분은 "req.user 어차피 안쓰는데 굳이 왜넣음?"이 포인트입니다. 이게 포인트가 될 경우 제가 반박 할 수가 없습니다. 그리고 req.user를 붙이지 않는 새로운 Guard를 생성하는 해결법은 말씀하신 포인트에 아주 적절히 잘 대응하신 부분이라고 말씀 드릴 수 있습니다.
혹시 애매한 답변처럼 느껴지셨다면 댓글로 다시한번 질문 주시면 추가로 답변 드리도록 하겠습니다!
감사합니다!