23-07-31 TIL (Bean, 인증 & 인가, 데이터 검증)

Bean

Bean을 수동으로 등록하는 방법

• 자동 등록

  • @Component를 사용하면 @ComponentScan에 의해 자동으로 스캔되어 해당 클래스를 Bean으로 등록
  • 프로젝트의 규모가 커질 수록 등록할 Bean들이 많아지기 때문에 자동등록을 사용하면 편리
  • 비즈니스 로직과 관련된 클래스들은 그 수가 많기 때문에 @Controller, @Service와 같은 애너테이션들을 사용해서 Bean으로 등록하고 관리하면 개발 생산성에 유리
    -> 정리 : 처리해야할 로직과 클래스가 많아져 여러 Bean들을 등록해야하기 때문에 일반적으로는 자동 등록하는 것

• 수동 등록 : 기술적인 문제나 공통적인 관심사를 처리할 때 사용하는 객체들을 등록할 때 사용

  • 공통 로그처리와 같은 비즈니스 로직을 지원하기 위한 부가적, 공통적인 기능들을 기술 지원 Bean이라 부르고 수동등록
  • 비즈니스 로직 Bean 보다는 그 수가 적기 때문에 수동으로 등록하기 부담스럽지 X
  • 수동 등록된 Bean에서 문제가 발생했을 때 해당 위치를 파악하기 쉽다
  • 예시 코드

  // 등록하는 메서드가 속한 해당 클래스에 @Configuration을 설정
  @Configuration
  public class PasswordConfig {
  
      @Bean  // 등록하고자 하는 객체 (BCryptPasswordEncoder) 를 반환하는 메서드
      public PasswordEncoder passwordEncoder() {
          // 등록하고자 하는 객체 반환
          return new BCryptPasswordEncoder();
      }
  }

  • Bean으로 등록하고자하는 객체를 반환하는 메서드를 선언하고 @Bean을 설정
  • Bean을 등록하는 메서드가 속한 해당 클래스에 @Configuration을 설정
  • Spring 서버가 뜰 때 Spring IoC 컨테이너에 'Bean'으로 저장
  • 이 때 등록되는 Bean의 이름은 메서드 명 (passwordEncoder) 이 된다.

같은 타입의 Bean 사용시

• @Primary
  • 같은 타입의 Bean이 여러 개 있더라도 우선 @Primary가 설정된 Bean 객체를 주입
  • 주입하려는 클래스 상단에 추가
• Qualifier
  • 주입하려는 클래스 상단 & 주입하려는 필드 상단에 추가
  • @Primary보다 우선순위가 더 높다.
  • 같은 타입의 Bean이 여러 개 있을 때는 범용적으로 사용되는 Bean 객체에는 Primary를 설정하고 지엽적으로 사용되는 Bean 객체에는 Qualifier를 사용하는 것이 좋다.
    -> @Qualifier는 적용하기 위해서 주입 받고자하는 곳에 해당 Qualifier를 반드시 추가해야하기 때문

인증과 인가

• 인증(Authentication)

  • 인증은 해당 유저가 실제 유저인지
    -> 예를 들어 쿠팡에 로그인하는 것 (실제 쿠팡에 가입된 사용자인지 확인하는 개념)

• 인가(Authorization)

  • 인가는 해당 유저가 특정 리소스에 접근이 가능한지 허가를 확인
    -> 사용자인지, 실제 해당 페이지 관리자인지 확인하는 것

• 인증 방식
  • 쿠키-세션 방식 (서버가 ‘특정 유저가 로그인 되었다’는 상태를 저장하는 방식)
    
    1. 사용자가 로그인 요청을 보냄
    2. 서버는 DB의 유저 테이블을 뒤져서 아이디 비밀번호를 대조
    3. 실제 유저테이블의 정보와 일치한다면 인증을 통과한 것으로 보고 “세션 저장소”에 해당 유저가 로그인 되었다는 정보 삽입
    4. 세션 저장소에서는 유저의 정보와는 관련 없는 난수인 session-id를 발급
    5. 서버는 로그인 요청의 응답으로 session-id를 보냄
    6. 클라이언트는 그 session-id를 쿠키라는 저장소에 보관하고 앞으로의 요청마다 세션아이디를 같이 보냄. (주로 HTTP header에)
    7. 클라이언트의 요청에서 쿠키를 발견했다면 서버는 세션 저장소에서 쿠키를 검증
    8. 유저정보를 받아왔다면 이 사용자는 로그인이 되어있는 사용자
    9. 이후에는 로그인 된 유저에 따른 응답
       
       
  • JWT 기반 인증 (인증에 필요한 정보들을 암호화시킨 토큰으로 식별)
    
    1. 사용자가 로그인 요청을 보냄
    2. 서버는 DB의 유저 테이블을 뒤져서 아이디 비밀번호를 대조
    3. 실제 유저테이블의 정보와 일치한다면 인증을 통과한 것으로 보고 유저의 정보를 JWT로 암호화 해서 내보냄
    4. 서버는 로그인 요청의 응답으로 jwt 토큰을 내어줌
    5. 클라이언트는 그 토큰을 저장소에 보관하고 앞으로의 요청마다 토큰을 같이 보냄
    6. 클라이언트의 요청에서 토큰을 발견했다면 서버는 토큰을 검증
    7. 이후에는 로그인 된 유저에 따른 응답.

데이터 검증

Validation

• 이 부분은 아주 잘 정리가 되어 있는 페이지가 있어서 링크를 남김
• Validation Annotaion List