[항해 14기] 개발일지30 (미니 프로젝트 - Auth/User기능 구현)

미니 프로젝트 주차

 

1. 진행사항

- 로그인, 로그아웃, 회원가입 진행

 

 

 

2. 새로 시도 한 것

- 기존 jwt 로그인 방식에서 access/refresh token 도입

- 로그아웃 구현

 

 

 

3. 고찰

1) 로그아웃

- 로그인 로직의 반대로 구성해주면 될 것으로 생각

- 로그인 로직 : 쿠키에 access/refresh token을 담아줬고, 이후 인증요청 시도 시 인증 미들웨어에서 토큰을 검증 한 뒤 이상 없으면 res.local에 로그인한 user의 정보를 담아줌, 이후 각 비즈니스로직에서 res.local 정보를 이용하여 로직 수행

- 로그아웃 로직 : 쿠키값들을 제거해주고, res.local 값을 삭제해줌

 

2) access/refresh token

- 기존 인증 로직은 jwt token으로 만들어진 access token으로만 진행

- 해당 토큰이 탈취당하면 서버측에서 대처가 곤란해짐

- 보안성 향상을 위해 refresh token을 추가

- 로그인 진행시 access/refresh token 을 발급해 줌과 동시에 refresh token을 특정 저장소에 추가

- 이후 인증 시도 시 기존의 액세스토큰 검증과 더불어 저장소에 있는 리프레쉬 토큰을 교차검증

- 토큰이 탈취 되었을 때 저장소의 리프레쉬 토큰을 만료/삭제 시켜주면 탈취된 토큰에 대한 방어가 가능

 

 

 

4. 트러블 슈팅

1) 문제 발생

- refresh token을 레디스가 아닌 db에 저장하는 것을 시도하다가 문제 발생

- 테이블을 잘못 생성하여 강제 드랍 하였는데 다른 테이블에 외래키가 걸려있는 상태였음

- MySQL 에서 외래 키 제약 조건을 가진 테이블을 강제로 드랍하면 해당 테이블과 연결된 외래 키 제약 조건을 가진 다른 테이블들에 영향을 줄 수 있는데, 해당 테이블과 연결된 외래 키 제약 조건을 가진 다른 테이블들은 유효한 데이터를 참조하지 못하게 되어 데이터의 무결성 깨지므로 이를 방지하기 위함.

- 외래 키 제약 조건을 가진 테이블을 드롭한 후, 다른 테이블들에 데이터를 생성하려고 시도하면 MySQL에서는 해당 외래 키 제약 조건에 위배되므로 데이터 생성이 실패하고 오류가 발생

 

2) 해결 시도

- 연계 되어있는 테이블들의 모델/시퀄라이즈 설정에서 외래키조건을 삭제하고 테이블을 모두 삭제한 뒤 새로 테이블생성 및 시퀄라이즈 구상

- 데이터가 모두 날아가므로 베스트 해결책이 아니라고 생각

- 이후 두가지 선택지가 존재하였는데

- 첫번째로, 임시테이블을 만들어 준 뒤 기존 테이블 값들을 복사 하여 데이터를 보존 해 준 뒤 위의 드랍/수정 작업을 지행한 뒤에 임시테이블을 사용할 테이블로 전한 해주는 방식

- 두번째 작업보다 시간이 많이 걸릴 것 같아 두번째 방식 선택

- 두번째 방식은 현재 작업한 모든 내용을 되돌려서 초기 pull받은 상태로 복구

- 복구를 하였으나, 작업한 데이터를 보관해두고 되돌리는 과정에서 보관 실수가 발생

 

3) 고찰

- 브랜치를 파서 작업을하였으면 체크아웃을 통해 작업한 데이터를 잃지 않으면서 기존 데이터로 돌아가기 가능, 이후 원하는 방식으로 재작업 후 브랜치 정리

- 브랜치를 파지 않아 위의 방식이 불가능 한 경우엔 git stash, git stash pop 명령어 이용

- 번외로 pull해온 레포지토리에변경이 있고, 변경된 파일로 푸쉬를 변경해야되는 경우 rebase명령어로 커밋이 남지 않는 유사 머지 가능