[ TIL ] 20240124

공부 시간

TODO

• 책 ( 객체지향의 사실과 오해 )
  - [ ] 20페이지 이상 읽기
• 알고리즘
  - [x] SQL 3문제 이상 풀기
• Spring
  - [x] 3주차 절반 이상 듣기

[!note]+ 복기

스프링 빈을 수동으로 등록하는 방법

• @configuration을 클래스에 선언해주고

• 클래스 안의 메소드에 @Bean을 선언해주면 수동으로 스프링에 빈으로 등록이 된다.

• new BCryptPasswordEncoder
  - 문자열을 Hash화 해주는 객체
  - encode(new String)
  - String을 hash화를 해줌.
  - matches( a,b ) a와 b를 비교해서 같으면 true를 반환

같은 타입의 빈이 두개라면

• 같은 타입의 빈이 두개이상일 때 지정해주는 방법

public interface food;

@Component
class pizza implements food
@Component
class chicken implements food

• food를 구현하고 Bean으로 등록된 구현체가 두개 있다면

1. 각자 하나씩 선언

   
   @Autowired
   Food pizza;
   
   @Autowired
   Food Chicken;
   

2. Primary로 사용안한다고 선언해주기
   - 넓 범위 선언

   @Component
   @Primary
   class chicken implements food

3. Qualifier("클래스 명")을 사용하여 우선순위 지정해주기
   - 좁은 범위 선언
   - 우선순위 Qualifier > Primary

   // 선언
   @Component
   @Qulifier("pizza")
   class pizza implements food{}

   // 사용
   @Autowired
   @Qulifier("pizza")
   Food food;

인증과 인가

• 인증 == 검문 == Authentication

• 인가 == 허용 == Authorization

• http 통신은 비연결성과 무상태성을 지닌다.

쿠키와 세션

일반적으로 http는 무상태성을 지니기 때문에 상태성을 유지하기 위한 방법이 필요하다. 그렇기에 사용되는 방식이 쿠키와 세션이다.

1. 쿠키

   클라이언트에 저장될 목적으로 생성한 작은 정보를 담은 파일 입니다.

2. 세션

   서버에서 일정시간 동안 클라이언트 상태를 유지하기 위해 사용됩니다.

   서버에서 클라이언트 별로 유일무이한 '세션 ID' 를 부여한 후 클라이언트 별 필요한 정보를 서버에 저장합니다.

   서버에서 생성한 '세션 ID' 는 클라이언트의 쿠키값 ('세션 쿠키' 라고 부름)으로 저장되어 클라이언트 식별에 사용됩니다.

JWT

코딩애플 참고
https://www.youtube.com/watch?v=XXseiON9CV0

회원가입

패스워드 암호화

• 클라이언트에서 요청으로 들어오는 패스워드들은 DB에 저장이 된다.
• 하지만 DB가 탈취되거나 해킹당하게 된다면 등록된 패스워드들은 쉽게 탈취당할 가능성이 높아진다.
• 그렇기에 패스워드는 DB에 저장이 될 때 아무도 알아볼 수 없게 암호화를 해서 저장이 되어야 한다.

양방향, 단방향 암호 알고리즘

• 양방향
  - 암호화: 평문 → (암호화 알고리즘) → 암호문
  - 복호화: 암호문 → (암호화 알고리즘) → 평문
  - 이와 같이 양방향으로 설계를 하면 암호화를 적용시킨 로직에 역으로 적용을 시키면 쉽게 뚫릴 수 있기에 양방향은 사용되지 않는다.

• 단방
  - 암호화: 평문 → (암호화 알고리즘) → 암호문
  - 복호화: 불가 (암호문 → (암호화 알고리즘) → 평문)

• passwordEncoder.matches( a, b )

if(!passwordEncoder.matches("사용자가 입력한 비밀번호", "저장된 비밀번호")) {
	throw new IllegalAccessError("비밀번호가 일치하지 않습니다."); 
}

• Spring security에서는 비밀번호를 암호화해주는 메서드를 가지고 있다.
• 암호화된 패스워드와 평문으로 된 패스워드를 비교해주는 메서드를 가지고 있어 굳이 암호화, 복호화 과정을 걸치지 않아도 자동적으로 비교가 가능해 로그인이 가능하다.

Filter

1. 요청 전처리 (Request Pre-processing): Filter는 클라이언트의 요청이 컨트롤러에 도달하기 전에 요청 데이터를 가로채어 사전 처리 작업을 수행할 수 있습니다. 예를 들어, 인코딩 설정, 인증, 로깅 등의 작업을 수행할 수 있습니다.

2. 응답 후처리 (Response Post-processing): 컨트롤러가 처리한 후, 응답이 클라이언트로 보내지기 전에 Filter는 응답 데이터를 가로채어 후처리 작업을 수행할 수 있습니다. 예를 들어, 응답 데이터의 압축, 보안 헤더 추가 등의 작업을 수행할 수 있습니다.

3. 체인의 일부로서 동작: 여러 개의 Filter는 체인 형태로 동작하며, 각 Filter는 다음 Filter로 요청과 응답을 전달합니다. 이로 인해 각 Filter는 자신이 수행해야 할 작업을 수행하고, 다음 Filter로 제어를 전달하여 체인을 통해 여러 단계의 처리를 할 수 있습니다.

• Jwt 토큰을 가지고 있다는 가정

1. 요청이 들어오면 filter에서 일단 jwt토큰이 있는지 없는지 검사한다.
2. JWT 토큰이 있다면 filter에서 검증을 하여 토큰이 존재하지 않으면 메인으로 이동이 불가하고 토큰이 존재하면 메인으로 들어갈 수 있다.
3. 만약 토큰이 존재하지 않으면 filter는 그대로 지나치고 controller단으로 넘겨져 request에 맞게 수행한다.