월요일에는 Lv3 과제 제출을 하고 JAVA 객체 지향을 다시 공부했다
화요일에는 Spring 심화 주차 강의를 들었고 Lv4 과제를 시작했다
수요일에는 Lv4 과제를 제출 했다 기존에 만들었던 것을 업그레이드하는 것이었어서 오래걸리진 않았다
제출 후에는 Spring 심화 주차 강의를 계속 들었고 다른 페어가 없어서 하지 못한 Lv3 과제 페어 리뷰도 했다
목요일에는 주간시험이 있었고 남은 Spring 심화 주차 강의를 모두 들었다 다행히 주간시험을 통과할 수 있었어서 기뻣다
금요일에는 주특기 프로젝트가 시작되었다 Spring 2명 React 2명이 한팀이 되었고 SA 를 작성했다
내가 맡은 것중에 회원가입 페이지를 구현했다
토요일에는 주특기 프로젝트의 로그인 페이지와 마이페이지 조회를 구현했고 저녁에는 Refresch Token 특강을 들었다
그리고 오늘은 간단히 CORS에 대해 알아보았다
1. CORS (Cross Origin Resource Sharing) 란?
1) 교차 출처 리소스 공유라고 하며 출처가 다른 자원들을 공유한다는 뜻으로 한출처에 있는 자원에서 다른 출처에 있는
자원에 접근하도록 하는 개념
2) 추가 HTTP 헤더를 사용하여, 한 출처에서 시행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는
권한을 부여하도록 브라우저에 알려주는 체제이다 웹 애블리케이션은 이로스가 자신의 출처
(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행한다
* 출처란?
https:// kim.github.io :433 /tech/svelte ?page=1 #Origin 란
Protocol host port 생략가능 Path Query String Fragmene
위의 구성요소 중에서 Protocol + Host + Port 3가지가 같으면 동일 출처 (Origin) 라고 한다
- 동일 출처 예시
| http://Example.com:80 http://example.com |
HTTP 기본 Port인 80번이 생략되어있으므로 동일 출처입니다 |
| http://example.com/app1/index.html http://example.com/app2/index.html |
Protocol, Host, Port(생략)이 같으며, Path부터 다르므로 동일 출처입니다 |
- 다른 출처 예시 다른 출처 요청일 경우, CORS 정책에 준수하여 요청해야만 정상적으로 응답을 받는다
| http://example.com/app1 https://example.com/app2 |
Protocol이 다릅니다 |
| http://example.com http://www.example.com http://myapp.example.com |
Host가 다릅니다 |
| http://example.com http://example.com:8080 |
80, 8080으로 포트가 다릅니다 |
2. CORS의 필요성
모든 곳에서 데이터를 요청할 수 있게 된다면 다른 사이트에서 원래 사이트를 흉내낼 수 있다
예를 들어 기존사이트와 완전히 동일하게 동작하도록 하여 사용자가 로그인을 하도록 하고 로그인했던 세션을 탈취하여
악의적으로 정보를 추출하거나 다른사람의 정보를 입력하는 등 공격이 가능하다
이렇게 공격을 할 수 없도록 브라우저에서 보호하고 필요한 경우에만 서버와 협의하여 요청 할 수 있도록 하기 위해
필요
3. CORS 동작
1) Simple requests인 경우
(1) 서버로 요청
(2) 서버에 응답이 왔을 때 브라우저가 요청한 Origin과 응답한 헤더 Access-Control-Request-Headers의 값을 비교하여
유효한 요청이라면 리소스를 응답하고 유효하지 않은 요청이라면 브라우저에서 이를 막고 에러가 발생함
* Simple requests란 아래와 같다 이요청은 추가적으로 확인하지 않고 바로 본 요청을 보낸다
HTTP method가 다음 중 하나이면서
- GET
- HEAD
- POST
자동으로 설정하는 헤더는 제외하고, 설정할 수 있는 다음 헤더들만 변경하면서
- Accept
- Accept-Language
- Content-Language
Content-Type이 다음과 같은경우
- application/x-www-form-urlencoded
- multipart/form-data
- text/plain
2) preflight 요청인 경우
(1) Origin 헤더에 현재 요청하는 origin과, Access-Control-Request-Method헤더에 요청하는 HTTP method와
Access-Control-Request-Headers 요청시 사용할 헤더를 OPTIONS 메서드로 서버로 요청한다 이때
내용물은 없이 헤더만 전송
(2) 브라우저가 서버에서 응답한 헤더를 보고 유효한 요청인지 확인함
만약 유효하지 않은 요청이라면 중단되고 에러가 발생하며 유효한 요청이라면 원래 요청으로 보내려던 요청을
다시 요청하여 리소스를 응답받는다
* Simple requests란 아래와 같다
- Simple requests가 아닌 cross-origin 요청은 모두 preflight 요청을 하게 되는데 실제 요청을 보내는 것이 안전한지
확인하기 위해 먼제 OPTIONS 메서드를 사용하여 cross-origin HTTP 요청을 보낸다.
이렇게 하는 이유는 사용자 데이터에 영향을 미칠 수 있는 요청이므로 사전에 확인 후 본 요청을 보냄
4. 요청 헤더 목록
1) Origin
2) Access-Control-Request-Method
(1) preflight 요청을 할 때 실제 요청에서 어떤 메섣를 사용할 것인지 서버에 알리기 위해 사용
3) Access-Control-Request-Headers
(1) preflight 요청을 할 때 실제 요청에서 어떤 header를 사용할 것인지 서버에 알리기 위해 사용
5. 응답 헤더 목록
1) Access-Control-Allow-Origin
(1) 브라우저가 해당 origin이 자원에 접근할 수 있도록 허용
(2) * 은 credentials이 없는 요청에 한해서 모든 origin에서 접근이 가능하도록 허용
2) Access-Control-Expose-Headers
(1) 브라우저가 엑세스할 수 있는 서버 화이트리스트 헤드를 허용
3) Access-Control-Max-Age
(1) 얼마나 오랫동안 preflight 요청이 캐싱 될 수 있는지를 나타냄
4) Access-Control-Aloow-Credentials
(1) Credentials가 true 일 때 요청에 대한 응답이 노출될 수 있는 지를 나타냄
(2) preflight 요청에 대한 응답의 일부로 사용되는 경우 실제 자격 증명을 사용하여 실제 요청을 수행할 수 있는지를
나타냄
(3) 간단한 GET 요청은 preflight 되지 않으므로 자격 증명이 있는 리소스 요청하면 헤더가 리소스와 함께 반환되지
않으면 브라우저에서 응답을 무시하고 웹 콘텐츠로 반환하지 않음
5) Access-Control-Allow-Methods
(1) preflight 요청에 대한 응답으로 허용되는 메서드들을 나타냄
6) Access-Control-Allow-headers
(1) preflight 요청에 대한 응답으로 실제 요청시 사용할 수 있는 HTTP 헤더를 나타냄
'항해99' 카테고리의 다른 글
| 23.09.19 항해 99 16기 주특기 프로젝트 4일차 (0) | 2023.09.19 |
|---|---|
| 23.09.18 항해 99 16기 주특기 프로젝트 3일차 (0) | 2023.09.18 |
| 23.09.16 항해 99 16기 주특기 프로젝트 2일차 (0) | 2023.09.16 |
| 23.09.15 항해 99 16기 주특기 프로젝트 1일차 (0) | 2023.09.15 |
| 23.09.14 항해 99 16기 주특기 Spring 19일차 (0) | 2023.09.14 |
