오늘 수업 제법 재밌었는데, 다 포스팅을 하고 잘 수 있을련지 모르겠다. 떼잉
오늘의 과제는 Redis를 이용하여 로그아웃을 구현하는 것이였다.
아마 이 글을 보고 있는 사람이라면, 딱 나와 비슷한 레벨의 수준일 것이기에
코드를 올려놓고 리뷰하는 식으로 진행을 하려고 한다.
auth.resolver.ts
/// 임포트 한 것들 ////
import { Cache } from 'cache-manager';
import { CACHE_MANAGER, Inject } from '@nestjs/common';
import * as jwt from 'jsonwebtoken';
///////////////////////////////////////////
constructor(
@Inject(CACHE_MANAGER)
private readonly cacheManager: Cache,
) {}
// 생성자 주입, Redis는 임시저장해주는 곳으로 사용하기 떄문에 흔히 캐시라고 부르는 것이라
// 이름도 캐시로 만들어져있다. (결국은 캐시가 레디스고 레디스가 캐시인 건가 싶기도 하고)
@Mutation(() => String)
async logout(
//
@Context() context: any,
//
// 생성자로 컨텍스트 받아오기, 이렇게 해놔야 프론트에서 쏘는 것들을 잡아올 수 있다.
// rest api라면 req로 받아왔을 듯?
//
) {
const refresh = context.req.rawHeaders
.filter((ele) => {
return ele.match(/refresh/);
})[0]
.split('=')[1];
const access = context.req.rawHeaders
.filter((ele) => {
return ele.match(/Bearer/);
})[0]
.split(' ')[1];
// 위에 토큰을 가져오는 것은 사람마다 차이가 있을 것 같다.
// headers에도 담겨있고
// rawHeaders에도 담겨있었는데
// headers가 객체의 형식으로 되어있어서 가져오기는 더 쉬울 것 같았는데
// 그냥 한번 남들과 다르게 해볼라고 써봤다(?)
// rawHeaders는 배열의 형식을 가지고 있고
// 데이터를 주고 받을 때 순서대로 쌓아서 보내준다고 한다
try {
jwt.verify(access, 'myAccessKey');
jwt.verify(refresh, 'myRefreshKey');
} catch {
throw new UnauthorizedException();
// 이것은 인증되지 않음을 뜻하는 용어(?)다
// 인증이 안되면 너 인증 안댔다. 하고 아래 있는 코드를 실행하지 않고 에러뱉고 멈춘다.
}
// 과제 조건이 try catch문을 쓰라는 것이여서 썼다.
// jwt.verify는 알아서 토큰을 검증을 해주는 작업을 해준다.
// ...가드를 왜만들었나 싶기도 해서 뭔가 어....음....
//
// 결국 jwt.sign은 토큰을 만들어주는 것
// jwt.verify는 토큰을 인증하는 역할을 한다.
//
// 아무튼 앞에는 해당하는 값을 넣고 뒤에는 비밀번호를 넣으면 된다.
// 나는 액세스토큰의 비밀번호는 myAccessKey
// 리프레시토큰의 비밀번호는 myRefreshKey의 형식으로 되어있어서 저렇게 넣었다.
//
//
await this.cacheManager.set(access, 'accessToken', { ttl: 120 });
await this.cacheManager.set(refresh, 'refreshToken', { ttl: 120 });
//
// 요것은 Redis의 문법이다.
// 형태는 앞에는 key, 뒤에는 value 한칸 더는 객체의 형태로 ttl 데이터가 생존해있는 시간을 적어넣을 수 있다.
// 만약에 0으로 쓸 경우 서버를 내리기 전까지 유지가 된다.
// 일단 저건 120초라는 의미다. s나 h같은거 붙여볼까...?
//
return '로그아웃에 성공했습니다';
//
// 확인해봤는데, 레디스에 저장되어있는 시간동안 재인증이 불가능해진다.
// ....왜? verify의 구조를 조금 더 알아봐야할 것 같다.
//
}
throw new UnauthorizedException(); 를 사용하면 발생하는 에러
jwt-access.strategy.ts
constructor(
@InjectRepository(User)
private readonly userRepository: Repository<User>,
@Inject(CACHE_MANAGER)
private readonly cacheManager: Cache,
// 여기는 검증을 하기 위하여 Redis를 불러올 것이기 때문에 캐시를 불러온다.
// 임포트는 똑같이 해주면 된다.
) {
super({
//
jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
secretOrKey: 'myAccessKey',
passReqToCallback: true,
//
// 이것을 사용하지 않으면, 토큰을 복호화했을 경우에 들어있는 값만 나온다.
// 만약 이것을 true로 해놓으면 일반적으로 컨텍스트 중 req가 포함되어있는 것을 받아볼 수 있다.
//
});
}
async validate(req, payload) {
// 위에 passReqTocallback을 설정해놨기때문에
// validate의 함수에 req 값을 받아올 수 있다.
const rawHeadersInAccessToken = req.rawHeaders
.filter((ele) => {
return ele.match(/Bearer/);
})[0]
.split(' ')[1];
// 이건 위에서 쓴 형식과 동일하다
//
const check = await this.cacheManager.get(rawHeadersInAccessToken);
//
// 로그아웃 당시 해당하는 액세스 토큰은 키가 되었고, 'accessToken은 값이 된 상태다.
// 그래서 로그아웃할 때 사용한 액세스 토큰이라면 값이 존재하여 true고
// 새로운 액세스 토큰으로 찾아오면 null이라는 값을 받게 된다.
//
if (check) throw new UnauthorizedException();
//
// 값이 존재하면 로그아웃 했던 것과 같은 토큰이기에 너 인증 안댓음! 에러 발송
// 아니면 코드는 아래로 흘러간다.
const user = await this.userRepository
.createQueryBuilder()
.where({ user_email: payload.user_email })
.getOne();
// 이것은 그냥 내 욕심에 넣어놓은 코드인데
// 나는 유저 id는 난수인 uuid로 생성되는 id고
// 실질적으로 쓰는 아이디는 email인데 쿼리문을 돌릴 때는 고유값인 PK를 가져와서
// 사용하는 것이 좋은 편이라
// 굳이 찾아와서 토큰 정보에 PK를 꽂아놓은 상태다.
return {
user_email: payload.user_email,
user_id: user.user_id,
};
// 아무튼 토큰정보에 이런거 담아서 넘겨줌 복호화하면 이메일이랑 id를 볼 수 있다.
}설정파일 속으로 들어왔을 때, StrategyOptions에 있는 것들
잘 보면 passReqToCallback을 사용하지 않을 경우인 VerifyCallback에는
req라는 값이 없지만
딱봐도 쓰는 것 같은
VerifyCallbackWithRequest의 인터페이스 속에는 req 타입이 존재하는 것을 확인할 수 있다.
그리고 저기 노란색으로 대문자인 Request는 express에서 땡겨쓰는 것이라
우리가 생각하는 웹 상의 리퀘스트가 된다.
리프레시 토큰도 똑같이 만들어놔서 굳---이 안올려도 될 것 같아서 그냥 패스한다!
Redis 쓰러갈거다.
물류 서비스 Backend Software Developer