Spring Security 도입 후 회원가입 불가 문제

배경

<aside> 🚨

Spring Security 를 도입하면서 Legacy code에 있던 whiteList를 제거함과 동시에, filterChain 메서드에서 requestMatcher 메서드를 통해 url 경로 별 인증 및 권한 확인을 추가한 상황이다.

</aside>

원인

<aside> 🔥

permitAll() 을 통해 회원가입 및 로그인 요청 경로에서 인증을 생략할 수 있도록 지정하였으나, 회원가입을 시도할 때 해당 정보로 사용자 정보를 조회하는 UserDetailsServiceImpl의 로직이 수행되는 문제가 발생했다.

</aside>

조치

<aside> 🚧

filterChain에서 HttpSecurity의 Session 옵션을 제거하면 해당 문제를 완화할 수 있었으나, JWT 기반의 Stateless 인증 인가 환경에서는 Session을 생성하지 않는 것이 적합하다고 판단되었다.

</aside>

대처

<aside> 🛠

정의한 인증 필터가 Spring Security Context와 연동되지 않는 OncePerRequestFilter를 상속하였기 때문에, 별도로 whiteList를 지정해주어야 했다. 이것을 조금 더 개선하려면 whiteList 데이터를 정적 전역 데이터로 공유하는 방법도 고려해 볼 수 있겠다.

</aside>

결론

<aside> ✅

여러 시행착오를 통해 Spring Security의 핵심 로직을 조금 더 이해할 수 있었으나, 그럼에도 유연하고 정확하게 사용하기는 너무나 버거운 라이브러리처럼 느껴져, 나중을 위해선 조금 더 인위적인 숙달 과정이 필요해 보인다.

</aside>

N + 1 문제에 대한 잘못된 이해

배경

<aside> 🚨

N + 1 문제에 대해, 단순히 한 테이블의 여러 데이터를 조회할 때 하나의 쿼리로 조회하기만 하면 되는 줄 알고, Repository의 일괄 조회 메서드를 사용하는 레거시 코드에서 문제점을 찾지 못하는 상황이다.

</aside>

원인

<aside> 🔥

Comment 테이블에서 목록화 조회를 수행하는 과정에서 N + 1 이 발생하는 지 테스트하기 위해, 단순히 하나의 User 로 로그인하여 N 개의 Comment 를 생성하여 조회하였고, 이 때 N에 관계 없이 2개의 쿼리가 발생하는 점을 의아하게 생각하였다.

</aside>

조치