Cookie와 Header

🛠️Cookie와 Header

 

Cookie

클라이언트가 서버에 로그인 요청

서버가 클라이언트에게 쿠키 발급

클라이언트는 쿠키를 신경 쓰지 않고 이후 요청에 자동으로 쿠키를 포함되어 서버에 요청 전송

Header

클라이언트가 서버에 로그인 요청

서버가 response body로 토큰 전달

클라이언트가 모든 요청에 Header에 토큰을 넣어서 서버에 요청 전송 → 클라이언트가 신경 쓰는 것.

 

PathVariable

RESTful api에서 리소스를 식별하기 위해 사용

 

vs.

 

Header

HTTP 통신에서 부가적 정보를 저장

POST → 필수적인 정보 전달 시 @RequestBody 필요

AuthController → 로그인, 회원가입, 로그아웃 등 구현 (로그아웃 시 쿠키 삭제)

UserController → 유저 정보 수정, 삭제

---

📍Tomcat

Web Server

: 정적인 리소스들을 반환하는 서버

Web Containner

: 동적인 리소스들을 반환하는 서버(DB와 소통)

Web ApplicationServer

: Web Server + Web Containner

Client → Controller → Service / Service → Controller → Client

주고 받는 데이터를 DTO에 담아서 전달

🪄DTO 사용 이유

1. client에서 model의 모든 정보를 알 필요가 없음
2. 필요한 정보만 주고받음

직렬화 native code → JSON

역직렬화 JSON → native code

response DTO에는 @GETTER 필수

request DTO는 @ReqeustBody로 정보 받아옴

Exception

• spring 자체에서 반환해주는 exception은 정보가 제한적이고, 친화적이지 않음
• 그러므로 CustomException 사용 → RuntimeException 상속 받음

@RestControllerAdvice ExceptionController

→ 예외에 대한 처리 (예외는 service에서 처리)

---

📍DB

• 하나하나 식별해줘야 함 ⇒ Primary Key 사용
• FK 규칙 ⇒ 피참조 테이블에서 pk, 참조 테이블에서 중복 가능
• Table == Entity

1) OneToMany

: 하나의 a가 여러 개의 b를 가질 수 있다.

 

2)ManyToMany

: 여러 개의 a가 여러 개의 b를 가질 수 있다.

→ 중간테이블 OneToMany로 연결

 

JPA

→ 쿼리를 직접 작성하지 않아도 됨.

→ java class와 DB 테이블 연동

→ java ORM

 

@OneToMany

→ cascade

• PERSIST - One 쪽 Entity에만 저장해도 해당 Entity에 속해있던 Many쪽 Entity도 같이 저장됨
• REMOVE - 부모가 삭제되면 자식도 전부 삭제
• OrphanRemoval - 고아 객체가 생기면 해당 객체 제거
  
  

1️⃣fetch

• LAZY : 지연 로딩.

→ 자식은 필요할 때 조회 됨. 즉, 필요한 상황이 생기면 그때 데이터를 가져옴. (쿼리를 날림)

• EAGER : 즉시 로딩.

→ 부모 조회 시 자식도 같이 조회 됨.

→ 즉시 데이터를 모두 가져옴.

 

2️⃣cascade

1. PERSIST
   : 저장 상태 전이
   → Team 아래 member 가 같이 저장됨.
2. REMOVE
   : 삭제 상태 전이
   → Team 아래 member 가 같이 저장됨.
3. MERGE
   : 업데이트 상태 전이
4. REFERESH
   : 갱신 상태 전이
5. ALL
   : 전체 상태 전이

3️⃣orphanRemoval

: 고아 객체 제거

• @OneToMany 또는 @OneToOne 부모 엔티티에서 사용.
• casecade.REMOVE 와 비슷함.
• 부모 객체에서 리스트 요소를 삭제했을 경우 해당 자식 객체는 매핑 정보가 없어지므로 대신 삭제해줌.

---

📍인증과 인가

**HTTP Stateless : 이전의 통신 상태 기억X.

 

인증 : 사용자의 신원을 검증

인가 : 사용자의 권한(유효성)을 검사

 

→ 토큰 방식

• 사용자의 정보를 담는 JWT를 클라이언트에게 반환.
• DB를 거치지 않아도 됨
• 클라이언트에서 인증 정보를 신경 써야 함. - JWT 노출

→ 세션 방식

• 사용자의 정보를 담은 세션을 생성해서 세션을 DB에 저장
• 클라이언트에서 인증 정보를 다루지 않음
• DB를 한 번 더 거쳐야 함

JWT 토큰

Cookie + Bearer {jwt}

→ 쿠키는 로그인 시 서버가 클라이언트에게 발급해줌. ⇒ 쿠키 안에 jwt

→ 클라이언트가 신경 X

 

jwt → payload 안에 넣을 정보를 담아서 키와 알고리즘을 통해 랜덤 문자열 반환

---

📍Password Hashing

→ user 회원가입 시 email, password를 그대로 저장.

→ DB 해킹 시 user 정보가 모두 유출됨 ⇒ 보안 문제

 

 

🪄solution

→ 알고리즘 + salt + 반복횟수 = HashedPssword

 

 

해싱의 특징

1. encoding은 가능
2. decoding은 불가능 - 큰 장점
3. 모든 결과가 항상 같음
   → salt와 반복 횟수가 같으면 항상 같은 암호를 얻음원래 DB에 사용자 비밀번호를 직접적으로 저장 → 보안성 문제
   → 비교 가능 match(plainPW, hashingPW)

 

🪄solution

**완벽한 보안은 없음

1. 회원가입 요청이 들어옴
2. 요청 DTO에서 pw 추출
3. 이 pw를 암호화
4. 암호화한 pw를 DB에 저장

 

• 암호화된 pw 비교하기

1. email, pw 로그인 요청 받음
2. 로그인DTO의 pw랑 DB의 pw랑 비교(회원가입 시 암호화돼서 둘은 다른 pw)
   → 암호화 키를 통해 비교함→ 하지만 비교를 통해 같은지는 알아낼 수 있음
   → pw를 decoding할 수 없음
3. 같으면 로그인 성공

 

• 암호화 과정

1. 특정 알고리즘 사용 → 거기에 salt를 추가
   **salt → 임의의 문자열, 암호화를 더 정교하게 할 수 있게 함.
2. 특정 횟수만큼 반복해서 암호화