[9 주차] 소성민 / Chapter09_Spring Security - JWT, OAuth - #43
soseongmin03 wants to merge 3 commits into
Conversation
| spring: | ||
| jpa: | ||
| show-sql: false | ||
| hibernate: | ||
| ddl-auto: validate | ||
| properties: | ||
| hibernate: | ||
| format_sql: false |
There was a problem hiding this comment.
application.yml 에 이미 spring: jpa: 설정이 있는데 따로 yml 파일에서도 중복되게 설정하신 이유가 있을까요?
prod 파일을 따로 만드신 게 환경별 설정 관리를 의도하신 것 같은데 똑같은 속성에 관한 설정이 두 파일에 중복되어 있으니 어떤게 실제로 프로젝트에 적용될 지 잘 모르겠어서 궁금합니다.
There was a problem hiding this comment.
말씀하신 것처럼 환경별 설정 관리를 의도하여 설계한 것입니다. application.yml을 먼저 읽고, spring.profiles.active=prod일 때 application-prod.yml 값을 병합or우선 적용하도록 설계하였습니다.
두 파일에 같은 설정이 중복되어 있기 때문에 충분히 햇갈렸을 수 있다고 생각합니다.
| @@ -1,7 +1,8 @@ | |||
| package org.example.swaggerpr.mission.entity; | |||
| package org.example.swaggerpr.store.entity; | |||
There was a problem hiding this comment.
스토어와 리전 두 개의 엔티티를 스토어 도메인으로 분리하신 이유가 궁금합니다. 엔티티와 리포지토리만 스토어 도메인에 존재하는데 이것들만 있어도 분리해야 할 이유가 있을까요?
There was a problem hiding this comment.
현재 상태에서는 “도메인 분리”보다는 “공통 참조 엔티티를 보관할 패키지를 미리 만든 것”에 가깝습니다.
현재 상태로는 이유가 부족하다고 생각하실 수 있지만 파트장님의 피드백을 기반으로 백엔드 관점에서 생각했을 때
mission이나 review에 종속된 데이터라기 보다는 여러 기능에서 참조할 수 있는 엔티티라고 생각해 분리하게 되었습니다.
또 추후에 store와 region에 대한 비즈비스 로직이 확장될 가능성을 열어두기 위해서의 이유도 있습니다.
| UserDetails user = customUserDetailsService.loadUserByUsername(email); | ||
| Authentication auth = new UsernamePasswordAuthenticationToken( | ||
| user, | ||
| null, | ||
| user.getAuthorities() | ||
| ); |
There was a problem hiding this comment.
JWT를 사용하는 가장 큰 이유는 서버가 DB를 보지않고도 토큰 서명만 보고 유효성을 검증할 수 있다는 점이라고 생각합니다. 제가 찾아보니까 현재 JWT를 쓰면서도 세션 방식을 사용할 때 처럼 요청마다 DB를 조회하고 있는 것 같습니다.
만약 사용자가 조금 더 많아진다면 DB에 부하가 많이 걸릴 것 같다는 생각이 듭니다.
(혹시 제가 잘못 알고 있는거면 알려주시면 감사하겠습니다..!)
|
로그인 자체가 어려운 부분이라서 다른 분들의 완성된 레포을 읽어보는 것도 많은 도움이 될 것이라고 생각합니다. 권한 정보를 저장하거나 생성하는 코드 자체가 없는 상태입니다.
// 예시 코드 필터(JwtAuthFilter.java:56)는 매 요청마다 loadUserByUsername으로 DB를 조회해 인증 객체를 만듭니다. 한편 토큰에는 email·role claim을 담아두었는데(JwtUtil.java) 이 claim은 검증에 활용되지 않습니다.
토큰 검증에 대한 조건이 부족합니다. 위에 코드로 잡혀 있는 경우 JwtException을 모두 한 번에 잡아 false로 반환합니다. 만료 토큰(ExpiredJwtException)과 서명 위조를 구분하지 못해, 클라이언트가 "토큰 갱신이 필요한지" vs "재로그인이 필요한지"를 알기 어렵습니다. 추후 RefreshToken을 도입한다면 만료를 별도로 잡아 다른 에러코드로 전달하는 것이 적절해 보입니다. getEmail()의 null 반환 처리
|
🔗 Issue Number
📝 개요
🚀 주요 변경 사항
🖼️ 실행 결과 (Screenshots)
💬 고민 및 질문
9주차 2번째 미션이 오류가 많이 발생하여 시간안에 해결이 안될 것 같아 일단 첫번째 미션만 해서 올렸습니다. 기간 이후에라도 완성해 올리도록 하겠습니다.
✅ 실습 체크리스트
⚙️ 환경 및 컨벤션 체크 (Final Check)