[ 비즈니스 상황 ] 결과적으로 한 줄 요약하면 학교 주변 식당 추천기이다. 과거에 했었던 프로젝트이고 조금 더 현실적이고 어려운 테스트 상황을 만들기 위해 실시간 옵션과 식당의 시작 시간과 종료 시간이라는 검색 조건을 추가하였다. 이 서비스 상황에 따라 어떻게 설계하고 테스트하며 작성할 지를 Practical Testing: 실용적인 테스트 가이드(인프런 박우빈) 강의를 들으며 배운 내용을 토대로 작성을 해보고자 한다. 사용될 기술은 MySQL, H2, Spring boot 2.7.16, Jpa, Querydsl로 과거 프로젝트는 타임리프로 제작했지만 이번엔 Restful하게 제작할 예정이다. [ 도메인 설계 ] 단순 추천 시스템이기 때문에 테이블은 딱 1개만 존재한다. 테이블 내부에는 식당의 이름, ..

공부를 하다보니 가끔씩 되게 헷갈리는게 있다. 어떤 건 생성자를 써줘야 하고 어떤 건 Getter를 넣어줘야 하는 것들, 잠깐 문제가 생겼을 때 블로그 글보고 찾아서 해결은 하지만 왜인지는 모르고 넘겼던 내용들에 관해 간단하게 한번 정리해보고자 한다. [ JPA는 protected 이상의 접근제어자를 가진 기본 생성자가 필요하다 ] 모델 영역에서 JPA를 통해 객체로 테이블 매핑을 하면 반드시 @NoArgsConstructor를 protected 이상으로 열어주어야 한다. 이는 JPA의 구현 방식 때문이다. JPA는 Reflection을 사용한다. 그 이유는 지연로딩 때문이다. JPA에서는 모든 연관관계를 필요하지 않다면 후에 미뤄서 가져오지 않는 지연로딩을 제공한다. 이를 통해 성능 최적화가 가능한데,..

[ 스프링의 Layered Architecture ] React는 라이브러리, Vue는 프레임워크, 스프링도 프레임워크라고 한다. 라이브러리와 프레임워크의 기본적인 차이는 제어의 권한을 누가 가지고 있는가에 따라 구분할 수 있다. 일반적인 Java 코드에서 Jackson라이브러리의 경우 그 코드는 도구이며 전체적인 흐름은 개발자가 직접 선택해서 정한다. 반면 스프링에서는 전체적인 흐름은 스프링에서 정해져 있고 최대한 역할을 분리할 수 있게 layered architecture 구조로 코드를 짜게 강제한다. 이런 구조의 장점 중 하나를 꼽아보라고 생각하면 컨트롤러 층이 가장 먼저 떠오른다. 특히 컨트롤러에서 우리는 @Request와 @Response를 어떻게 처리할 지만 따로 처리만 한다. 개발자가 직접 ..

[ 리프레시 토큰과 구현 로직 설명 ] 3편에서 JWT 토큰을 이용한 로그인 이후 발급되는 AccessToken를 유저에게 주었다. JWT 토큰의 특성으로 인해 DB 없이 상태유지를 하지 않고도 서명 시스템으로 인해 위조 여부를 판단할 수 있었다. 또한, JWT 토큰 내부 정보로 사용자의 아이디와 권한 정보를 이용해 불필요한 인증과정을 없앴다. 문제는 AccessToken은 강력한 권한을 가지고 있다. 서버 내에 저장되어있지 않기 때문에 AccessToken이 빼았겨버리면 만료시간까지 그 유저의 모든 권한을 공격자가 가질 수 있다. 그렇다고 보안을 위해 만료시간을 줄여버리면 사용자가 로그인을 매번해야 하는 불편함이 있다. 보통 이 문제를 해결하기 위해 RefreshToken과 Redis를 이용한 구현을 ..

[ 고민거리 ] 스프링 시큐리티를 사용하면서 AccessToken을 사용했을 때는 DB 내용이 섞여들어가지 않았었다. 그런데, RefreshToken을 사용하니 필터에 DB 커넥션이 필요한 로직들이 필터 내부에 섞여 들어가기 시작했다. 또한 필터가 영속성 컨텍스트 범위 바깥이라 필터 내부에서 DB에서 찾아온 객체 내부의 값을 변경해도 변경이 반영이 되지 않았었다. 그래서 아래와 같은 코드가 나왔다. JWTTokenValidation.java @Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException,..

[ 문제 상황 ] 스프링 시큐리티로 로그인을 구현할 때에는 Basic Authentication을 사용해 구현을 했었다. 이 때 로그아웃이랑 엑세스 토큰의 재발급을 위해 리프레시 토큰을 도입하고 구현을 했다. 그런데 logout 페이지를 컨트롤러로 작성해 url을 "/logout"으로 해놨더니 해당 url로 보내는 요청만이 작동을 하지 않았었다. 이유를 보고 나니, 스프링 시큐리티는 기본적으로 로그인은 "/login", 로그아웃은 "/logout"으로 url이 설정되어있고 config에서 기본 설정을 바꿔주지 않아서 발생한 문제였다. 결과적으로는 "/login/logout"으로 주소를 바꿔놓기만 한 상태인데, 시간이 남으면 로그인과 로그아웃 필터에 관해서 정확하게 알아보고 스프링 시큐리티 기본 지원 로그..