[React] Day_41 데일리 정리

 

누더기 골렘같은 내 프로작뜨 ^-^)b..

 

기능 구현 싸아아아아아그리몽땅 다했는데

Vercel 배포에서 애먹은 사람? 저요.

근데 알고보니 정말 별것도 아닌

알파벳 한 끗 차이로 오류난 거였다는 것에 현타온 사람? ..저요.

이거 때문에 뭐지 뭐지 하면서

결국 다른 기능... 구현 하면서 밤 샌 사람?  ........저 yo.

히히 개인과제 정리는 내일해야징..

가보자...goyo

 

 

 

챌린지반 스터디 정리 - CORS? COR..S!

너가 유일한 희망이야... RG?

 

ㅎ... 해볼게? (와장창)

 

CORS(크로스 오리진 리소스 공유의 줄임말)

로드된 도메인 → 다른 도메인의 리소스, 안전하게 요청 + 애플리케이션을 통합 위해 허용하는 메커니즘

(or 상호 작용하는 클라이언트 웹 애플리케이션)

why? → 클라이언트 측 코드, 서드 파티 API 및 리소스를 참조하는 경우가 많기 때문)

ex) 브라우저 통해 동영상 플랫폼 API에서 동영상 가져오기, 공용 글꼴 라이브러리의 글꼴 사용

사용 시, 클라이언트 ⇒ 브라우저에서 데이터, 전송 전 서드 파티 서버를 check → 요청 승인 여부 파악 가능

CORS의 중요성

CSRF 문제를 방지하기 위해! 모든 브라우저에서 동일 오리진 정책을 구현

CSRF (크로스 사이트 요청 위조) : 피해자의 브라우저 → 다른 애플리케이션, 가짜 클라이언트 요청 전송

ex) 피해자 속여 새 브라우저 탭에 외부 웹 사이트 로드.

→ 피해자 쿠키 보안 인증 정보 사용 및 데이터 릴레이

→ 피해자로 위장, 은행 애플리케이션에 데이터를 전달가능

→ 권한이 없는 사용자, 은행 애플리케이션 액세스 권한, 의도치 않게 부여

 

동일 오리진 정책

 

클라이언트, 클라이언트의 URL과 동일한 오리진의 리소스로만 요청 가능. (현재 브라우저 기준)

클라이언트 URL의 프로토콜, 포트 및 호스트 이름 = 클라이언트 요청 서버와 모오오오두 일치..!

ex) URL의 오리진 / 클라이언트 URL http://store.aws.com/dir/page.html 의 오리진 비교

URL	성과	이유
http://store.aws.com/dir2/new.html	동일한 오리진	경로만 다름
http://store.aws.com/dir/inner/other.html	동일한 오리진	경로만 다름
https://store.aws.com/page.html	다른 오리진	다른 프로토콜
http://store.aws.com:81/dir/page.html	다른 오리진	다른 포트(http:// 는 기본적으로 포트 80임)
http://news.aws.com/dir/page.html	다른 오리진	다른 호스트

 

동일 오리진 정책은 매우 안전하지만 실제 사용 사례에는 유연하지 않다.

왜?? → CORS, 동일 오리진 정책을 확장한 것 ⇒ 외부 승인 하에 리소스를 공유하기 위해선 CORS 필요

ex) 공개되거나 승인된 외부 API에서 데이터 가져오고 싶다 or 권한 있는 서드 파티, 서버 리소스에 액세스하는 것을 허용하고 싶다

→ CORS 필요

 

CORS 작동방식

브라우저, 애플리케이션 서버에 HTTP 요청을 보내고 HTTP 응답으로 데이터를 수신하여 표시

• 브라우저 용어를 알아보아요 ^-^)b
• 브라우저 URL = 현재 오리진 / 서드 파티 URL = 크로스 오리진

크로스 오리진 요청 시 요청-응답 프로세스

1. 브라우저, 현재 오리진의 프로토콜, 호스트 및 포트에 대한 정보 포함된 오리진 헤더 요청에 추가
2. 서버, 현재 오리진 헤더 확인 + 요청된 데이터 및 Access-Control-Allow-Origin 헤더로 응답
3. 브라우저, 액세스 제어 요청 헤더 확인 후 반환된 데이터 → 클라이언트 애플리케이션과 공유
4. if 서버에서 크로스 오리진 액세스를 허용하지 않는다? → 오류 메시지로 응답

예제

 

https://news.example.com이라는 사이트가 있다고 합시다.

사이트 : partner-api.com에서 API 리소스에 액세스하고 싶어! 라고 할..때

'https://partner-api.com' 의 개발자는 어떻게 해야 할까요?

→ 먼저 new.example.com을 허용된 오리진 목록에 추가, CORS 헤더를 구성.

서버 구성 파일에 ‘ Access-Control-Allow-Origin: https://news.example.com ‘ 추가

CORS 액세스 구성 시, news.example.com에서 partner-api.com의 리소스 요청 가능.

모든 요청에 partner-api.com, Access-Control-Allow-Credentials : "true"로 응답

(따라서) 브라우저에선 응답을 통해 통신이 승인되었음을 인지, 크로스 오리진 액세스 허용

cf. 여러 오리진에 대한 액세스 권한을 부여하고싶다?

→ 쉼표로 구분된 목록 or *와 같은 와일드카드 문자 사용, 모든 사용자에게 액세스 권한을 부여해주자.

 

CORS 사전 요청

요청 메서드 in HTTP : 클라이언트가 서버를 통해 수행하고자 하는 데이터 작업

일반적인 HTTP 메서드 : GET, POST, PUT 및 DELETE

일반적인 CORS 상호 작용에서 브라우저, 요청과 액세스 제어 헤더를 동시에 전송

→ 해당 요청, 일반적으로 GET 데이터 요청 + 위험이 낮은 것으로 간주

But, 일부 HTTP 요청, 복잡한 것으로 간주 → 실제 요청을 보내기 전 서버 확인 프로세스 (사전 요청) 필요.

복잡한 크로스 오리진 요청

크로스 오리진 요청 중 하나가 사용되는 경우, 해당 요청 = 복잡한 요청

• GET, POST 또는 HEAD 외의 메서드
• Accept-Language, Accept 또는 Content-Language 외의 헤더
• multipart/form-data, application/x-www-form-urlencoded 또는 text/plain 외의 Content-Type 헤더

ex) ‘ 기존 데이터를 삭제하거나 수정하라 ’ 라는 요청, 복잡한 것으로 간주

 

사전 요청 작동 방식

사전 요청이 필요한 경우, 브라우저에서 사전 요청 생성.

(해당 요청 = OPTIONS 요청)

• OPTIONS /data HTTP/1.1
• Origin : https://example.com
• Access-Control-Request-Method: DELETE

브라우저, 실제 요청 메시지 전 사전 요청 보냄

서버, 클라이언트 URL에 수락할 의향이 있는 크로스 오리진 요청에 대한 정보 사용

→ 사전 요청 응답 필요.

 

서버 응답 헤더에 포함되어야 하는 내용들

• Access-Control-Allow-Methods
• Access-Control-Allow-Headers
• Access-Control-Allow-Origin

서버 응답의 예시

• HTTP/1.1 200 OK
• Access-Control-Allow-Headers: Content-Type
• Access-Control-Allow-Origin : https://news.example.com
• Access-Control-Allow-Methods : GET, DELETE, HEAD, OPTIONS

사전 요청 응답, 경우에 따라 Access-Control-Max-Age 헤더가 추가로 포함

Access-Control-Max-Age : 브라우저에서 브라우저의 사전 요청 결과를 캐시하는 기간(초)을 지정

캐싱 사용 시, 브라우저에서 사전 요청 사이에 여러 복잡한 요청을 전송 가능

max-age로 지정된 시간이 경과하기 전까지 다른 사전 요청 안보내도 됨!

 

 

CORS와 JSONP의 차이점?

JSONP(JSON with Padding) : 서로 다른 도메인에서 실행되는 웹 애플리케이션 간의 통신을 가능하게 하는 기존 기술

JSONP를 사용 시, 클라이언트 페이지에서 HTML 스크립트 태그 사용 가능!

스크립트 태그는 외부 JavaScript 파일을 로드 or HTML 페이지에 JavaScript 코드를 직접 임베드

스크립트에는 동일 오리진 정책이 적용 X, JavaScript 코드를 통해 크로스 오리진 데이터 검색 가능!

BUT, 데이터 = JSON 형식! 외부 도메인의 신뢰성에 의존 → 안전한 데이터 제공 CORS보다 덜 안전합니다.

현재 브라우저, 몇 가지 보안 기능이 추가 → JSONP가 포함된 오래된 코드는 더 이상 작동하지 않는다..!

CORS는 크로스 오리진 액세스 제어를 위한 최신 글로벌 웹 표준입니다.

 

 

 

 

마무리 - 과제 결론이 뭐냐고요? 이젠 이거 쓰세요. 아시겠어요?  ye?

 

저흰 똑똑한 친구들만 쓰자고요.. 근데 어렵네 쯧

 

오늘이 진짜진짜 지이이인짜 프로젝트 끝나고 쉬는 마지막..날이 되지 않을..까?

원래 정말 끝나자마자 쉬고 싶었는데

집 계약문제 이슈때문에.. 집에 갑자기 사람이 들이닥치고.. ㅖ...

전화도 이것저것 오고.. 뭐랄까.. 기빨리네요.. (E도 기빨려요. 정.말.로.)

그래서 오늘 TIL 쓰고 뭐할거냐면여..

일단 오바와-찌 끌라식 나왔으니 이거 몇판 할 거고 (이젠 섬난의 시대야.)

음.. 그러고 자야지.

정말 자야지.

자..야지

쿨...

(대충 마무리 인사)

 

 

KPT 회고

• Keep :  아 오늘도 깔쌈하게 다 끝내따.
• Problem : 어제 오전 8시부터 깨있었으니까.. 응? 너 도대체 몇시간동안 깨어있는거야?
• Try : 잠 좀 제대로 주무세요.. ye?

 

ㄲ

-

ㅌ