mode: 'no-cors'
จะไม่ทำให้สิ่งต่าง ๆ ทำงานได้อย่างน่าอัศจรรย์ ในความเป็นจริงมันทำให้สิ่งเลวร้ายลงเพราะมีผลอย่างหนึ่งที่จะบอกเบราว์เซอร์“ บล็อกโค้ด JavaScript ส่วนหน้าของฉันจากการดูเนื้อหาของส่วนตอบสนองและส่วนหัวภายใต้สถานการณ์ทั้งหมด” แน่นอนว่าคุณแทบไม่ต้องการสิ่งนั้นเลย
เกิดอะไรขึ้นกับคำขอข้ามที่มาจากส่วนหน้า JavaScript คือเบราว์เซอร์โดยรหัสเริ่มต้นบล็อกส่วนหน้าจากการเข้าถึงแหล่งข้อมูลข้ามแหล่ง หากAccess-Control-Allow-Origin
อยู่ในการตอบสนองเบราว์เซอร์จะผ่อนคลายการบล็อกและอนุญาตให้โค้ดของคุณเข้าถึงการตอบกลับ
แต่ถ้าไซต์ไม่ส่งAccess-Control-Allow-Origin
คำตอบโค้ดส่วนหน้าของคุณจะไม่สามารถเข้าถึงการตอบสนองโดยตรงจากไซต์นั้น โดยเฉพาะอย่างยิ่งคุณไม่สามารถแก้ไขได้โดยการระบุmode: 'no-cors'
(อันที่จริงแล้วจะทำให้แน่ใจว่าโค้ดส่วนหน้าของคุณไม่สามารถเข้าถึงเนื้อหาการตอบกลับได้)
แต่สิ่งหนึ่งที่จะทำงานถ้าคุณส่งคำขอของคุณผ่านพร็อกซี่ล ธเช่นนี้
var proxyUrl = 'https://cors-anywhere.herokuapp.com/',
targetUrl = 'http://catfacts-api.appspot.com/api/facts?number=99'
fetch(proxyUrl + targetUrl)
.then(blob => blob.json())
.then(data => {
console.table(data);
document.querySelector("pre").innerHTML = JSON.stringify(data, null, 2);
return data;
})
.catch(e => {
console.log(e);
return e;
});
<pre></pre>
หมายเหตุ: หากคุณลองใช้ https://cors-anywhere.herokuapp.com คุณจะพบว่ามันหยุดทำงานคุณสามารถปรับใช้ proxy ของคุณกับ Heroku ได้อย่างง่ายดายในเวลาเพียง 2-3 นาทีโดยมี 5 คำสั่ง:
git clone https://github.com/Rob--W/cors-anywhere.git
cd cors-anywhere/
npm install
heroku create
git push heroku master
หลังจากใช้คำสั่งเหล่านั้นคุณจะจบลงด้วยเซิร์ฟเวอร์ล ธ ทุกที่ของคุณเองทำงานที่เช่นhttps://cryptic-headland-94862.herokuapp.com/ ดังนั้นแทนที่จะนำหน้า URL คำขอของคุณด้วยhttps://cors-anywhere.herokuapp.com
นำหน้าแทนด้วย URL สำหรับอินสแตนซ์ของคุณเอง เช่นhttps://cryptic-headland-94862.herokuapp.com/https://example.com
ฉันสามารถเข้าถึงจุดสิ้นสุดนี้http://catfacts-api.appspot.com/api/facts?number=99
ผ่านบุรุษไปรษณีย์ได้
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORSอธิบายว่าทำไมถึงเป็นแม้ว่าคุณจะสามารถเข้าถึงการตอบกลับกับบุรุษไปรษณีย์ได้ แต่เบราว์เซอร์จะไม่ยอมให้คุณเข้าถึงการตอบสนองข้ามส่วนหน้าจากส่วนหน้า รหัส JavaScript ที่ทำงานในเว็บแอพเว้นแต่ว่าการตอบกลับจะรวมAccess-Control-Allow-Origin
หัวข้อการตอบกลับไว้ด้วย
http://catfacts-api.appspot.com/api/facts?number=99ไม่มีAccess-Control-Allow-Origin
ส่วนหัวการตอบสนองดังนั้นจึงไม่มีวิธีที่รหัสส่วนหน้าของคุณสามารถเข้าถึงการตอบสนองข้ามจุดกำเนิดได้
เบราว์เซอร์ของคุณสามารถตอบสนองได้ดีและคุณสามารถดูได้ในบุรุษไปรษณีย์และแม้แต่ในเบราว์เซอร์ devtools - แต่นั่นไม่ได้หมายความว่าเบราว์เซอร์จะเปิดเผยรหัสของคุณ พวกเขาจะไม่ได้เพราะมันไม่มีAccess-Control-Allow-Origin
ส่วนหัวตอบสนอง ดังนั้นคุณต้องใช้พร็อกซีเพื่อรับมันแทน
พร็อกซีทำการร้องขอไปยังไซต์นั้นรับการตอบสนองเพิ่มAccess-Control-Allow-Origin
ส่วนหัวการตอบกลับและส่วนหัว CORS อื่น ๆ ที่จำเป็นจากนั้นส่งต่อกลับไปยังรหัสที่คุณร้องขอ และการตอบสนองที่Access-Control-Allow-Origin
เพิ่มส่วนหัวนั้นเป็นสิ่งที่เบราว์เซอร์เห็นดังนั้นเบราว์เซอร์จึงอนุญาตให้โค้ดส่วนหน้าของคุณเข้าถึงการตอบสนองได้
ดังนั้นฉันพยายามส่งผ่านวัตถุไปยัง Fetch ของฉันซึ่งจะปิดใช้งาน CORS
คุณไม่ต้องการทำเช่นนั้น เพื่อให้ชัดเจนเมื่อคุณบอกว่าคุณต้องการ“ ปิดการใช้งาน CORS” ดูเหมือนว่าคุณหมายถึงคุณต้องการปิดใช้งานนโยบายต้นทางเดียวกัน CORS เองเป็นวิธีการทำเช่นนั้น - CORS เป็นวิธีการคลายนโยบายที่มาดั้งเดิมไม่ใช่วิธีที่จะ จำกัด
แต่อย่างไรก็ตามมันเป็นความจริงที่คุณสามารถทำได้ในสภาพแวดล้อมท้องถิ่นของคุณทำสิ่งต่าง ๆ เช่นให้ธงเบราว์เซอร์รันไทม์ของคุณเพื่อปิดการรักษาความปลอดภัยและทำงานอย่างไม่ปลอดภัยหรือคุณสามารถติดตั้งส่วนขยายเบราว์เซอร์ภายในเครื่องเพื่อรับนโยบายเดียวกัน เปลี่ยนสถานการณ์สำหรับคุณในท้องถิ่น
ไม่ว่าคุณจะเปลี่ยนอะไรในเครื่องก็ตามใครก็ตามที่พยายามใช้แอปของคุณจะยังคงทำงานในนโยบายต้นทางเดียวกันและไม่มีทางที่คุณจะปิดการใช้งานสำหรับผู้ใช้แอปอื่น ๆ ของคุณ
คุณมักจะไม่ต้องการใช้mode: 'no-cors'
ในทางปฏิบัติยกเว้นในบางกรณีที่ จำกัดและแม้ว่าคุณจะรู้ว่าสิ่งที่คุณทำและผลกระทบคืออะไร นั่นเป็นเพราะสิ่งที่การตั้งค่าmode: 'no-cors'
จริงพูดกับเบราว์เซอร์คือ"ปิดกั้นโค้ด JavaScript ส่วนหน้าของฉันจากการดูเนื้อหาของส่วนตอบสนองและส่วนหัวในทุกสถานการณ์ ในกรณีส่วนใหญ่เห็นได้ชัดว่าไม่ใช่สิ่งที่คุณต้องการ
เท่าที่เป็นกรณีที่คุณจะต้องการพิจารณาใช้mode: 'no-cors'
ให้ดูคำตอบในสิ่งที่ข้อ จำกัด นำไปใช้กับการตอบสนองทึบแสง? สำหรับรายละเอียด ส่วนสำคัญของมันคือกรณีที่:
ในกรณีที่ จำกัด เมื่อคุณกำลังใช้งาน JavaScript เพื่อนำเนื้อหาจากแหล่งกำเนิดอื่นเป็น<script>
, <link rel=stylesheet>
, <img>
, <video>
, <audio>
, <object>
, <embed>
หรือ<iframe>
องค์ประกอบ (ซึ่งทำงานเพราะการฝังตัวของทรัพยากรข้ามจุดที่ได้รับอนุญาตสำหรับผู้) - แต่ด้วยเหตุผลบางอย่างที่คุณ don' ไม่ต้องการหรือไม่สามารถทำได้เพียงแค่ให้มาร์กอัพของเอกสารใช้ URL ของทรัพยากรเป็นhref
หรือsrc
แอตทริบิวต์สำหรับองค์ประกอบ
เมื่อสิ่งเดียวที่คุณต้องการทำกับทรัพยากรคือการแคช ดังที่กล่าวถึงในคำตอบข้อ จำกัด อะไรที่นำไปใช้กับการตอบสนองแบบทึบแสง? ในทางปฏิบัติสถานการณ์ที่นำไปใช้คือเมื่อคุณกำลังใช้บริการแรงงานซึ่งในกรณีนี้ API ที่เกี่ยวข้องคือการจัดเก็บแคช API
แต่แม้ในกรณีที่ จำกัด เหล่านั้นก็มี gotchas สำคัญที่ต้องระวัง; ดูคำตอบที่ข้อ จำกัด อะไรที่นำไปใช้กับการตอบกลับทึบแสง? สำหรับรายละเอียด
ฉันยังพยายามส่งผ่านวัตถุ { mode: 'opaque'}
ไม่มีmode: 'opaque'
โหมดคำขอ - opaque
แทนที่จะเป็นเพียงคุณสมบัติของการตอบสนองและเบราว์เซอร์จะตั้งค่าคุณสมบัติทึบแสงในการตอบสนองจากคำขอที่ส่งมาพร้อมกับno-cors
โหมด
แต่โดยบังเอิญคำว่าทึบแสงเป็นสัญญาณที่ชัดเจนเกี่ยวกับธรรมชาติของการตอบสนองที่คุณลงท้ายด้วย:“ ทึบแสง” หมายความว่าคุณไม่สามารถมองเห็นได้
cors-anywhere
วิธีแก้ปัญหาสำหรับกรณีใช้งานที่ไม่ใช่การแยงแบบง่าย ๆ (เช่นดึงข้อมูลที่เปิดเผยต่อสาธารณชนบางส่วน) คำตอบนี้ยืนยันความสงสัยของฉันที่no-cors
ไม่ธรรมดาเพราะ OpaqueResponse ไม่มีประโยชน์มาก เช่น "กรณีที่ จำกัด มาก"; ทุกคนสามารถอธิบายตัวอย่างที่no-cors
มีประโยชน์ให้ฉันได้หรือไม่