이 개념은 내가 이해했다고 생각했지만 최근에는 모두 잘못되었다는 것을 알았습니다. 나는 인터넷을 둘러 보면서 작은 세부 사항과 코드 스 니펫에 대한 많은 예제를 찾았지만, 여전히 그것이 무엇을 방해하는지, 왜 그것을 막는 지에 대한 이해가 부족합니다. 그래서 이것은 질문보다 높은 수준의 설명을 요구하는 것입니다.교차 출처 xhr 및 동일 출처 정책
것은이 전 도메인 A.com 및 도메인 B.com 있다고 가정 해 봅시다 :
은 어쨌든, 여기에 내가 그것에 대해 이해 무슨 생각입니다. 각각은 자신의 IP 주소를 가진 자신의 아파치 서버에있다. 도메인 A.com에서 브라우저로 html 파일을로드합니다. 브라우저는 POST XMLHttpRequest에서 B.com/doStuff.php로 실행합니다. 동일한 도메인 정책이 설정되어있어 실패합니다.그래서 : 누가 동일한 도메인 정책과 관련이 있습니까? 나는 대답이 B.com/doStuff.php라고 생각하는데 ... 맞습니까? 그래서 A가 요청을 보냈을 때 B는 요청 헤더에서 출발지를 확인한 후 "whoops, different domain, hear not you"라고 말합니다. 또는 A가 요청을 보내고 B가 "same-domain-policy"를 지정하는 헤더로 응답 한 다음 브라우저는 same-domain-policy가 지정되었고 A 요청의 헤더에서 도메인이 일치하지 않는지 확인합니다 BROWSER가 xhr을 발송하기를 거부 한 B 요청의 사람?
그렇다면 "출처를 초월한 요청을 허용하지 않는 이유는"내 API에 액세스하는 다른 사람을 원하지 않기 때문입니다. 그게 다야? 왜냐하면 당신은 어떤 종류의 인증으로 대신 그것을 해결하기를 원하지 않으니 까? 누군가가 가짜 기원 헤더 (단순히 거짓말)로 HTTP 요청을 구성 할 수 없습니까?
또는 어떻게 든 사용자를 보호하기로되어 있습니까? 그렇다면 API를 다른 사람을 보호하도록 전화하는 것을 어떻게 막을 수 있습니까?
난 너무 혼란 스러워요...
예를 들어 말풍선을 사용하여 기계가 URL을 가져 오는 것을 멈추지 않으며 브라우저 기반의 가져 오기를 중지하려고 시도합니다. non-js 위협을 차단하려면 인증해야합니다. 핵심은 명시 적으로 허용하지 않고 사이트의 콘텐츠를 서명되지 않은 JS로 다시 포함시킬 수 없다는 점입니다. – dandavis
@dandavis는 그다지 피하는 것이 쉽지 않습니까?그냥 자바 스크립트 요청을 귀하의 서버 (예 : 곱슬)와 그것을 가져옵니다 다음 다시 자바 스크립트에 전달 ... 요점은 무엇입니까? – Phildo
요점은 통제와 책임입니다 : 서버/PHP 코드는 신용 카드에 등록되어 있습니다. 일반 오래된 웹 페이지는 아닙니다. 귀하의 예에서는 컬을 수행하는 서버를 쉽게 식별하고 차단할 수 있지만 트래픽이 광고 삽입 자바 스크립트에서 오는 경우 요청은 모든 곳에서 올 수 있습니다 ... – dandavis