1. Exception Handling 및 Validation 논의:
•
현재 모든 익셉션의 상태 코드를 400으로 설정했으며, 추후 수정이 필요
•
Validation 규칙에 대한 논의. 비밀번호 확인은 프론트엔드에서 처리하고, 백엔드에서는 비밀번호의 복잡성 등 세부 규칙을 검증
•
Validation 규칙:
•
이름: 2~10자
•
이메일: @ 양식에 맞게
•
비밀번호: 소문자, 대문자, 숫자, 특수문자를 포함한 8~15자
•
생년월일: 현재 날짜 이전 날짜만 허용
•
선호음료 및 역할: ENUM 값으로 처리
•
프로필 사진: 최대 길이 255자
2. Validation 및 Exception 처리 코드 업데이트:
•
Validation 관련 코드가 업데이트되었고, 에러 응답 형식도 수정됨
•
ResponseEntity를 사용해 상태 코드를 헤더에 직접 설정하고, 바디에는 에러 메시지만 담는 방식으로 변경
3. 회원 조회 시 삭제된 데이터 처리:
•
회원 조회 시 삭제된 데이터를 제외하려면 @Where 대신 @SQLRestriction을 사용(@Where 어노테이션은 deprecated 되었기 때문)
•
@SQLDelete를 활용해 삭제 시 deleted_at 필드를 업데이트하도록 설정
4. JWT 및 OAuth 로그인 시나리오 작성:
•
직접 로그인:
•
회원가입: 프론트에서 비밀번호 일치 여부 확인 후 백엔드로 전달, 백엔드에서 유효성 검사 후 DB에 저장
•
로그인: 프론트에서 로그인 정보를 전달받아 백엔드에서 JWT 토큰 생성 및 전달
•
로그인 후 접근 시: 프론트에서 쿠키에 저장된 토큰을 헤더에 담아 요청, 백엔드에서 토큰을 검증 후 응답
•
구글 로그인:
•
사용자가 구글 로그인 후 받은 Auth code를 백엔드에 전달하여 JWT 토큰 생성
•
프론트에서 받은 토큰으로 요청 시 백엔드에서 검증 후 응답
5. JWT 토큰 만료 및 재발급 논의:
•
JWT 토큰 만료 시 새 액세스 토큰을 발급하는 로직을 추가
•
토큰 만료 여부 확인, 토큰 재발급 시 로직 구현
•
JWT 토큰의 만료 시간을 설정하고, 만료 시에는 재로그인을 요구하는 방식으로 구현할 예정
6. 액세스 토큰 시나리오:액세스 토큰 만료 시
1.
만료된 액세스 토큰 사용 -> 서버 요청
2.
서버는 액세스 토큰 만료 인지 -> 사용자에게 에러 응답
3.
사용자는 리프레시 토큰을 사용해 새로운 엑세스 토큰 발급 서버 요청
4.
리프레시 토큰 유효하면, 서버는 새로운 엑세스 토큰 발급
5.
리프레시 토큰 만료되면, 다시 로그인 요구
•
리프레시 토큰 사용해서 리프레시 토큰 갱신
◦
리프레시 토큰 사용해서 리프레시 토큰 새로 발급하면, 클라이언트는 로그인 상태 영원히 유지될 것
◦
리프레시 토큰 갱신은 지양, 만료 시 로그인을 다시 요구하는 방식