WIL

이번주는 주특기 심화 주차동안 코드랑 더 익숙해지며, 더 디테일하게 개념을 복습하는 과정을 했다. 하지만 기능 하나하나를 분리해서 인식하지 못하고 너무 통째로 크게 보고 있다는 피드백을 받았다. 그래서 이번 미니프로젝트 시작에도 틈틈이 코드 작성을 처음부터 연습하는 시간을 가지며, 기능 하나하나를 분리하며 천천히 진행해봐야할 것 같다.

 

그리고 미니 프로젝트를 한지 이틀 밖에 되지 않았지만, 협업하면서 얼마나 많은 의사소통이 필요한지 느꼈고 서로 확인하는 절차를 같이 밟아나갔음에도 실수하는 부분이 있는 것을 느꼈다. 개발자들에게 의사소통이 얼마나 중요한지 더 느끼게 됐고 시간을 많이 들이며 꼼꼼히 확인도 잘 해야함을 느꼈다.

그리고 프론트엔드에서 가능한 게 무엇인지 서로 어떻게 조율해나갈 것인지 맞추는것도 중요하게 느꼈다.

 

그리고 이번에 협업 세션을 들었던 내용을 정리하며 마무리 한다.

 

CORS

Origin = 출처

URL에서 프로토콜, 도메인, 포트 번호를 합친 부분이다.

 

https://c-ding.tistory.com/manage/newpost/?type=post&returnURL=%2Fmanage%2Fposts%2F 

프로토콜(Scheme으로도 불림) = https://

도메인(Domain) = c-ding.tistory.com

포트번호는 cmd에서 netstat -ano를 입력하면 확인할 수 있다.

 

ex) Origin = https://c-ding.tistory.com/:80 

 

브라우저 정책

SOP(Same Origin Policy) : 동일 출처 정책 = 다른 Origin으로 요청을 보낼 수 없도록 금지하는 기본 보안 정책

CORS(Cross Origin Resource Sharing) : 교차 출처 자원 공유 = 다른 Origin으로 요청을 보내는 것을 허용하는 정책

 

* CORS 요청을 제외한 나머지 경우는 요청 시 Sec-Fetch-Mode 헤더의 값을 no-cors로 설정해줘야 한다.

 

CORS 동작 원리

브라우저는 다른 Origin으로 요청을 보낼 때 Origin 헤더에 자신의 Origin을 설정하고, 서버로부터 응답을 받으면 응답의 Access-Control-Allow-Origin 헤더에 설정된 Origin의 목록의 요청에 Origin 헤더 값이 포함되는지 검사한다.

= Access-Control-Allow-Origin 헤더에 Origin을 설정하거나 와일드 카드 (*) 를 설정해주면 된다.

 

CORS의 요청 종류

1. 단순요청

Origin 헤더에 자신의 Origin을 설정하고, 서버로부터 응답을 받으면 응답의 Access-Control-Allow-Origin 헤더에 설정된 Origin의 목록에 요청의 Origin 헤더 값이 포함되는지 검사한다.

 

2. 프리플라이트 요청

서버에 실제 요청을 보내기 전에 예비 요청에 해당하는 프리플라이트 요청(Preflight Request)을 먼저 보내서 실제 요청이 전송하기에 안전한지 확인한다. 만약 안전한 요청이라고 확인이 된다면, 그때서야 실제 요청을 서버에게 보낸다. 따라서 총 두 번의 요청을 전송한다.

 

3. 인증 정보를 포함한 요청

쿠키(Cookie) 혹은 Authorization 헤더에 설정하는 토큰 값 등을 함께 포함해 보내는 요청이다.

쿠키 등의 인증 정보를 보내기 위해서는 클라이언트 단에서 요청 시 별도의 설정이 필요하다.

*응답의 Access-Control-Allow-Origin 헤더가 와일드카드(*)가 아닌 분명한 Origin으로 설정되어야 하고, Access-Control-Allow-Credentials 헤더는 true로 설정되어야 한다.