-
SOP에 대해 이해할 수 있다.
o
SOP는 Same Origin Policy의 줄임말로 동일 출처 정책을 의미한다.
'동일 출처 정책'은 같은 출처의 리소스만 공유가 가능하다는 정책이다.출처(origin)는
프로토콜 (https://) + 호스트(www.naver.com) + 포트(:443)의 조합을 의미한다. ex) https://www.naver.com:443
이 중 하나라도 다르면, 동일한 출처라고 보지 않는다.SOP은 동일한 출처의 리소스만 공유한다는 정책으로
이는 해로울 수 있는 문서를 분리함으로써
공격받을 수 있는 경로를 줄여주는 보안상의 이점을 가진다.이로 인해 다른 사이트와의 리소스 공유가 제한된다.
이는 보안상으로는 좋지만, 다른 출처의 리소스를 사용하게 될 일이 굉장히
많기 때문에 이러한 경우들을 해결하기 위한 방법으로 CORS가 있다. -
CORS에 대해 이해할 수 있다.
o
CORS는 Cross Origin Resource Sharing의 약자로,
교차 출처 리소스 공유를 의미한다.'교차 출처 리소스 공유'는 추가 HTTP 헤더를 이용하여,
하나의 출처에서 실행 중인 웹 애플리케이션이
또 다른 하나의 출처에 접근할 수 있는 권한을 부여하도록
브라우저에 알려주는 체제다.따라서 브라우저는 SOP에 의해
기본적으로 다른 출처의 리소스 공유를 막지만,
CORS를 사용하면, 접근 권한을 얻을 수 있다.만약, 다른 출처의 리소스를 가져오려고 할 때,
SOP 때문에 접근이 불가한 경우,
CORS 설정을 통해 서버의 응답 헤더에
'Access-Control-Allow-Origin을 작성하면,
접근 권한을 얻을 수 있다. -
CORS 동작 방식에 대해 이해할 수 있다.
o
(1) Preflight Request- 클라이언트는 브라우저에
실제 요청을 한다. - 요청을 받은 브라우저는 서버에
Preflight Request(사전 요청)을 보내서 - 👆 서버로 부터 응답 헤더에
'Access-Control-Allow-Origin'으로 요청을 보낸 출처가
돌아오면,실제 요청을 보내게 된다. - ✌️ 서버로 부터 응답 헤더에
'Access-Control-Allow-Origin'으로 요청을 보낸 출처가
접근 권한이 없다면,CORS 에러를 띄운다. - 이때, 서버는 요청을 수행하고,
- 브라우저에 응답을 보낸다.
- 응답을 받은 브라우저는 클라이언트에게 요청에 대한 응답을 보낸다.
(2) SImple Request
특정 조건이 만족되면, (프리플라이트 요청을 생략하고) 요청을 보낸다.
특정 조건에는-
GET, HEAD, POST 요청 중 하나여야 한다.
-
자동으로 설정되는 헤더 외에
Accept, Accept-Language, Content-Language, Content-Type 헤더의 값만
수동으로 설정할 수 있다.- Content-Type 헤더에는
application/x-www-form-urlencoded,
multipart/form-data,
text/plain 값만 허용된다.
- Content-Type 헤더에는
(3) 인증정보를 포함한 요청(Credentialed Request)
요청 헤더에 인증 정보를 담아 보내는 요청.
출처가 다른 경우에는 별도의 설정을 하지 않으면,
민감 정보이기 때문에 쿠키를 보낼 수 없다.
이 경우에는 클라이언트와 서버 양측 모두 CORS 설정이 필요하다.클라이언트 측) 요청 헤더에 withCredentials : true 을 넣어줘야 한다.
서버 측) 응답 헤더에 Access-Control-Allow-Credentials : true 를 넣어줘야 한다.이때, Access-Control-Allow-Origin을 설정할 때,
모든 출처를 허용한다는 뜻의 와일드카드(*)로 설정하면, 에러가 발생한다.
출처를 명확하게 설정해줘야 한다. - 클라이언트는 브라우저에
-
CORS 설정 방법을 이해한다.
o
1) Node.js 서버
2) Express 서버
cors가 무엇인지 알아보고 node.js를 이용하여 서버를 구축한다.
mini-node server를 공식 문서를 참고하여 직접 만들어보고,
express로 리팩토링해 본 후,
지난 스프린트에서 사용된 StatesAirline의 API Server를 직접 구현하면서
라우팅하는 방법을 학습한다.
같은 JavaScript를 사용하지만,
node.js 환경에서 사용하는 코드에는,
CommonJS나 모듈 등 브라우저에서
찾아볼 수 없는 다소 생소한 개념이 포함되어 있다.
node.js에서 사용하는 이 개념들은 백엔드뿐만 아니라,
프론트엔드에서도 적극 사용한다.
이번 유닛에서 구축하는 API 서버는 프론트엔드 개발자라도 구현할 수 있어야 한다.
새로운 서비스를 만들려고 해도,
필요한 데이터를 저장하거나 불러오는 기본적인 API 서버를 구현할 수 없다면,
아무런 동적 활동을 할 수 없는 클라이언트만 구현하게 될 것이다.
그리고 node.js에 대한 내용은
프론트엔트와 백엔드 등 웹 개발에서 공통적으로 사용하므로
반드시 학습해야 한다.
과제 Mini Node Server
브라우저에는 서버에 요청을 보내기 위해
fetch 같은 HTTP 요청을 보내는 도구가 기본적으로 내장되어 있다.
서버는 클라이언트(브라우저)의 HTTP 요청에 맞게
응답을 보낼 수 있도록 코드를 작성해야 한다.
Node.js는 HTTP 요청을 보내거나, 응답을 받을 수 있는 도구들을 제공한다.
HTTP 요청을 처리하고 응답을 보내 주는 프로그램을
웹 서버(Web Server)라고 부른다.
이번 과제에서는 Node.js의 http 모듈을 이용하여 웹 서버를 만든다.
Node.js에서 파일을 읽거나 쓰기 위해 fs 모듈을 사용하듯이,
HTTP 요청과 응답을 다루기 위해 HTTP 모듈을 사용한다.
HTTP 모듈 공식 문서에 들어가면, 방대한 양의 메서드가 있다.
공식 문서를 읽고 문제를 해결하는 게 가장 중요하지만,
어디서부터 접근해야 할지 결정하는 일은 다소 어렵다.
Node.js가 제공하고 있는
HTTP 트랜잭션 해부(Anatomy of an HTTP Transaction)
공식 가이드 문서를 통해
Mini-Node Server를 완성하는 데 큰 도움을 받을 수 있다.
키워드 하나하나를 전부 이해하겠다는 생각보다는,
가이드에 따라 코드를 직접 작성하면서
요청을 보내거나 받는 방식을 확인해 본다.
반드시 코드를 직접 작성해 보아야 한다.
소감
🔡➡️💻➡️🤓👍
비동기 처리부터 어려움을 겪고 있지만,
간단한 서버를 구동하는 것이 어려우면서도 재밌었다.
오늘은 페어분과 오래 소통하면서
작성한 코드에 toLowerCase 버튼이 작동하지 않고,
서버 응답 실패가 떴었는데,
이는 내가 url이 /lower일 때,
담아줄 그릇 역할을 하는 body에 빈 배열을 할당하지 않아서
서버가 담겨오지 않았던 에러였다. 😭
이걸 페어분이 30분 정도 고민하시다가 발견하셔서 해결했다.
역시 2인 이상의 집단 지성이 이래서 필요한가 보다..👍
혼자서는 절대 보이지 않았던 부분이었는데..
다만, 아직도 의아한 부분은
처음에는 코드를 작성한 후에
브라우저에서 요청을 보냈을 때, Get 요청은 200 응답 코드를 잘 받아왔는데,
/upper 과 /lower은 터미널에 작성은 되는데, 응답을 받지 못했는데
갑자기 /upper은 응답 받아와서 대문자로 바뀌는데,
/lower은 응답 받지 못했다. 이 부분은 왜 그런지 이유을 알 수 없었다..😵💫
아무튼 나는 페어분께 pull request로 과제 제출하는 부분에서
Git 명령어를 설명하면서 더 명확하게 개념이 잡혔다.
나도 이때 배울 때, 너무 복잡하고 어려워서 책 하나 살까 고민했던 건데
설명하면서 머릿속에서 더 명확하게 정리가 되었다.
오늘은 평소보다 더 뜻깊고 뿌듯한 날이다.
6월의 시작이 좋다! 👍
