Refactoring/ReviewRanger4 [리뷰레인저] JWT 토큰에 포함된 유저 정보를 제거하자 - 4 해당 게시글은 프로젝트 '리뷰레인저'에 대해 개인 리팩토링 과정을 정리한 시리즈 글입니다. 이번 게시글의 주제는 'JWT 토큰의 Payload에 포함된 유저 정보로 인한 개인정보 유출 위험에 대한 개선안'입니다. 기존 로직의 문제점 위 사진은 JWT 구조를 설명하고 있다. 이 중 내용(payload)에 집중해서 보면 ‘사용자의 권한 정보’와 ‘사용자 데이터’가 들어있음을 알 수 있다 여기서 중요한 것은 아래 주의 문구를 보자 즉, 페이로드에 중요한 값을 넣어두면 누구든 디코딩을 통해 값을 열람할 수 있기 때문에 민감한 정보는 포함하면 안된다는 내용이다. 그렇다면? 지금 나의 코드는 어떠한 정보를 포함한 JWT 토큰을 생성하고 있는지 확인해보자 UserPrincipal은 Spring Security의 Us.. 2024. 4. 13. [리뷰레인저] 페이징에 사용되는 Slice 도메인 객체의 노출 범위를 조정하자 - 3 해당 게시글은 프로젝트 '리뷰레인저'에 대해 개인 리팩토링 과정을 정리한 시리즈 글입니다. 이번 게시글의 주제는 '페이징에 사용되는 Slice 객체가 외부에 노출되는 현상에 대한 개선안'입니다. 개요 Slice 객체는 spring.data 패키지에 존재하는 것을 바탕으로 리팩토링을 진행하자! (패키지 범주를 잘 생각해보자) 우리가 왜 controller에서 entity를 노출하지 않는가? 외부에 의해 수정될 위험이 있기때문이다 entity는 domain영역이다. 마찬가지로 slice 객체도 domain영역에 존재한다. 그래서 entity 대신에 우리는 Response라는 객체를 만들어 사용한다 이와 똑같은 맥락으로 생각해보면 된다 Slice 객체의 범주 Controller → Service → Repo.. 2024. 4. 12. [리뷰레인저] DB에 불필요하게 쌓이는 RefreshToken을 해결하자 - 2 해당 게시글은 프로젝트 '리뷰레인저'에 대해 개인 리팩토링 과정을 정리한 시리즈 글입니다. 이번 게시글의 주제는 '유효한 refreshToken뿐만 아니라 무효한 refreshToken까지 DB에 무의미하게 쌓이는 현상에 대한 개선안'입니다. 기존 로직의 문제점 RefreshToken이 불필요하게 DB에 주기적으로 저장되어 문제가 발생했다 지금은 local에서 테스트 한 환경이지만 refreshToken의 유효시간은 24시간으로 만약 사용자가 많아지고 24시간이 지난다면 이러한 불필요한 만료 토큰 데이터가 계속해서 쌓이게 될 것이다 그리고 위 데이터를 보면 알 수 있다싶이 refreshToken이 `user_id`를 가지고 있어야한다 그렇다면 차라리 user가 refreshToken을 가지고 있다면 어떨.. 2024. 4. 10. [리뷰레인저] 확장성을 해치는 swtich 분기문을 없애자 - 1 해당 게시글은 프로젝트 '리뷰레인저'에 대해 개인 리팩토링 과정을 정리한 시리즈 글입니다. 이번 게시글의 주제는 'swtich문에 의한 로직의 유지보수성, 확장성이 저하되는 현상에 대한 개선안'입니다. 기존 로직의 문제점들 서비스 로직은 이름과 내부를 봤을 때 어떤 기능을 수행하는지 딱 알 수 있어야 한다 위 사진이 내부와 이름으로 어떤 기능을 수행하는지 바로 알 수 있는 예시이다 `getAllFinalReveiwResults` 메소드는 모든 최종 리뷰 결과를 가져오는 메소드 이름 + 유저id와 상태로 모든 최종 리뷰를 가져오는 기능임이 한번에 보인다. 1) 최종 리뷰를 생성하고 조회하는 로직은 어떤 기능을 수행하는지 알기 힘든 문제 위의 사진이 최종 리뷰를 생성하는 로직이다. 하지만 create라는 이.. 2024. 4. 9. 이전 1 다음
