[내일배움캠프 TIL] 1일차 - Spring. 시작

오늘부터 내일배움캠프를 시작하였습니다.

Spring 기본부터 배우기 시작했습니다.

실무에서 보았던 코드들이지만 이론은 잘 몰랐던, 그런 내용들을 학습할 수 있었습니다.

지난주에 들었던 강의와 오늘 들었던 강의들 중에 중요하다고 생각되는 개념들을 정리해보았습니다.

1. 오늘의 학습 키워드

entity, bean, JWT, session, filter(전처리, 후처리)

spring security

 

2. 핵심 키워드 상세 정리

Entity

• 정의: 데이터베이스의 테이블과 1:1로 매핑되는 Java 클래스입니다.
• 역할: 데이터베이스의 영속성(Persistence)을 가지는 최소 단위이며, JPA 등을 사용할 때 테이블 레이아웃을 정의하는 역할을 합니다.
• DB를 좀 더 쉽게 사용하기 위한 클래스라 생각됨. 영속성은 Transactional, 여러 동작을 한번에 묶어서 할 수 있음. 하나라도 실패되면 revert

Bean

• 정의: Spring IoC(제어의 역전) 컨테이너가 관리하는 자바 객체입니다.
• 역할: 개발자가 직접 new 연산자로 생성하지 않고, 스프링이 객체의 생명주기를 관리하며 필요한 곳에 의존성 주입(DI)을 해줍니다.

JWT (JSON Web Token)

• 정의: 당사자 간에 정보를 JSON 형태로 안전하게 전송하기 위한 개방형 표준(RFC 7519) 토큰입니다.
• 특징: 서버에 상태를 저장하지 않는(Stateless) 인증 방식이며, 클라이언트가 토큰을 보관하고 요청 시마다 헤더에 담아 전송하여 인증을 받습니다.

Session

• 정의: 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그 정보를 서버에 저장하는 기술입니다.
• 특징: JSESSIONID 쿠키를 통해 클라이언트를 식별하며, 서버의 메모리를 사용하여 정보를 유지하므로 보안성은 좋으나 서버 리소스를 점유한다는 특징이 있습니다.

Filter (전처리, 후처리)

• 정의: DispatcherServlet에 요청이 전달되기 전후에 URL 패턴에 맞는 요청을 가로채는 역할을 합니다.
• 역할: * 전처리: 보안 인증, 공통 로깅, 한글 인코딩 처리 등을 수행합니다.
  • 후처리: 응답 데이터를 압축하거나 추가적인 가공을 할 때 사용됩니다.
• 실무에서 Filter를 많이 보았는데, 기본적인 구조구나? 라고 알게됨.

Spring Security

• 정의: Spring 기반 애플리케이션의 인증(Authentication)과 인가(Authorization)를 담당하는 프레임워크입니다.
• 역할: 필터 체인(Filter Chain) 방식을 사용하여 보안 처리를 효율적으로 관리하며, 복잡한 보안 로직을 커스텀하게 설정할 수 있도록 지원합니다.

 

3.  이슈

Spring Security 강의를 따라하는데,  Security로 바꾸고 나서, 로그인시 계속 로그인 페이지로 돌아가는 이슈가 있었습니다.

중간에 놓친 부분이 있었는지, 이전 필터를 사용하여 구현했던 코드랑 꼬여서 그랬는지 모르겠는데,  (아님 강의랑 실제 코드랑 뭔가 다른부분이있었는지..?)

분석하여 수정하였습니다. (Gemini CLI 활용)

 1) 문제 현상 
   * 로그인 시 아이디/비밀번호를 맞게 입력했음에도 404 에러(Whitelabel Error Page)가 발생하거나, 로그인이 성공하여 세션(JSESSIONID)은 생성되는데 다시 로그인 페이지로 튕기는(Redirect) 현상
     발생.

  2)주요 원인 (Cause)
   1. 컨트롤러 중복 정의 (Conflict):
       * WebSecurityConfig에서 .loginProcessingUrl("/api/user/login")을 설정하여 Security가 로그인 처리를 하도록 지정했으나, UserController에도 동일한 경로의 @PostMapping 메서드가 직접
         구현되어 있어 충돌 발생.
   2. 인증 방식의 불일치 (Session vs JWT):
       * 서버는 Spring Security의 기본값인 세션(Session) 방식으로 로그인을 처리하여 JSESSIONID를 생성함.
  3)해결 방법 (Solution)
   1. 중복 컨트롤러 제거: UserController에서 직접 구현한 로그인(PostMapping) 메서드를 삭제하여 Spring Security가 온전히 인증 과정을 제어하도록 수정.
   2. 프론트엔드 로직 수정: basic.js에서 쿠키가 없을 때 로그인 페이지로 보내는 강제 리다이렉트 코드를 주석 처리하여 세션 로그인 상태가 유지되도록 함.
   3. Thymeleaf를 활용한 UI 제어: 자바스크립트(쿠키 체크) 대신 서버사이드 템플릿 엔진인 Thymeleaf의 th:if 속성을 사용하여, 서버에서 넘어온 인증 정보(username)의 유무에 따라 로그인/로그아웃
      버튼을 동적으로 노출.
   4. @AuthenticationPrincipal 활용: HomeController에서 Spring Security가 관리하는 인증 객체를 직접 주입받아 사용자의 정보를 모델에 담아 전달.

  💡 핵심 교훈
   * Spring Security를 도입할 때는 직접 구현한 인증 로직과 Security 필터 체인이 충돌하지 않는지 반드시 확인해야 한다.
   * 서버의 인증 방식(Session/JWT)과 프론트엔드의 인증 확인 로직은 항상 동일한 메커니즘을 공유해야 한다.