วิดีโอและคำบรรยาย · ตัวดาวน์โหลดสื่อโดยตรง
เหตุใด CORS สามารถบล็อกการดาวน์โหลดโดยตรงในเบราว์เซอร์ได้ และความหมายคืออะไร
· มันทำงานอย่างไร
cors http ดาวน์โหลด
ตัวดาวน์โหลดเฉพาะเบราว์เซอร์อาศัยอยู่ภายในนโยบายที่มีต้นกำเนิดเดียวกัน โพสต์นี้จะอธิบายว่า CORS คืออะไร เหตุใดบางโฮสต์จึงอนุญาตให้ดึงข้อมูลและบางโฮสต์ไม่อนุญาต และเหตุใดเครื่องมือที่ไม่มีเซิร์ฟเวอร์รีเลย์จึงไม่สามารถแก้ไขได้
ลิงก์ใช้งานได้ในแท็บใหม่ แต่ใช้งานไม่ได้ในเครื่องมือ - ปริศนาที่ข้อผิดพลาด CORS สร้างขึ้นสำหรับผู้ใช้
กล่องพอดแคสต์อาจเล่นเมื่อป้อนในแถบที่อยู่ แต่จะล้มเหลวเมื่อเพจพยายามอ่านด้วยการดึงข้อมูล การนำทางและการอ่านสคริปต์เป็นพลังของเบราว์เซอร์ที่แตกต่างกัน รายการแรกจะแสดงทรัพยากร ส่วนที่สองอาจเปิดเผยไบต์ให้กับโค้ดที่ทำงานบนแหล่งกำเนิดอื่น
Direct Media Downloader ต้องการพาวเวอร์ตัวที่สองเนื่องจากจะอ่านส่วนการตอบสนอง รายงานความคืบหน้า สร้าง Blob และนำเสนอการบันทึกที่มีชื่อ เมื่อโฮสต์สื่อไม่ได้เลือกใช้การอ่านแบบข้ามต้นทาง เบราว์เซอร์จะหยุด JavaScript จากการรับการตอบกลับ แม้ว่าการนำทางแบบธรรมดาอาจยังทำงานอยู่ก็ตาม ความแตกต่างเดียวกันนี้อธิบายว่าทำไมการคัดลอกที่อยู่ไปยังแอปพลิเคชันอื่นจึงสามารถสร้างผลลัพธ์ที่แตกต่างออกไปโดยที่แอปพลิเคชันใดไม่ได้เปลี่ยนไฟล์ระยะไกล
นโยบายที่มีต้นกำเนิดเดียวกันในย่อหน้าเดียว — เหตุใดหน้าบน toolacre.com ไม่สามารถอ่านไบต์ที่ให้บริการจากแหล่งกำเนิดอื่นได้อย่างอิสระ
ต้นทางผสมผสานโครงร่าง ชื่อโฮสต์ และพอร์ต หน้าเว็บที่แสดงจาก ToolAcre และไฟล์ที่แสดงจากผู้เผยแพร่ CDN จึงมักจะมีต้นกำเนิดที่แตกต่างกัน นโยบายต้นทางเดียวกันป้องกันไม่ให้สคริปต์ของต้นทางหนึ่งอ่านการตอบกลับของต้นทางอื่นได้อย่างอิสระ ปกป้องข้อมูลที่เปิดเผยผ่านการเข้าถึงเบราว์เซอร์โดยรอบ
ข้อจำกัดนี้บังคับใช้โดยเบราว์เซอร์ ไม่ใช่ตามคำเตือนที่สร้างขึ้นในตัวดาวน์โหลด ใช้ก่อนที่โค้ดของแอปพลิเคชันจะสามารถตรวจสอบส่วนหัวหรือส่วนเนื้อหาที่ได้รับการป้องกันได้ โฮสต์ต้นทางอาจยังคงได้รับคำขอ ดังนั้นการอ่านที่ถูกบล็อกจะต้องไม่ถูกอธิบายว่า "ไม่มีการติดต่อใดๆ" ขอบเขตของจุดเริ่มต้นมีผลกับการตอบกลับที่อ่านได้ ไม่ใช่เฉพาะกับนามสกุลไฟล์เท่านั้น ดังนั้นคำต่อท้าย `.mp3` ที่เห็นได้ชัดเจนจึงไม่มีการยกเว้นเป็นพิเศษสำหรับสคริปต์ของหน้า
Access-Control-Allow-Origin ทำอะไรได้บ้าง — วิธีที่โฮสต์ของไฟล์ ไม่ใช่เครื่องมือ ตัดสินใจว่าเบราว์เซอร์จะมอบไบต์ได้อย่างไร
เซิร์ฟเวอร์ระยะไกลสามารถเลือกใช้งานได้โดยส่งคืนส่วนหัว `Access-Control-Allow-Origin` ที่เหมาะสม การตัดสินใจนั้นเป็นของการกำหนดค่าของโฮสต์ไฟล์ ToolAcre ไม่สามารถเพิ่มส่วนหัวในการตอบกลับของผู้อื่นได้ และตัวเลือกคำขอไม่สามารถให้สิทธิ์แก่เซิร์ฟเวอร์ที่รับที่ถูกระงับได้
ส่วนหัวที่อนุญาตอนุญาตให้เบราว์เซอร์เปิดเผยการตอบสนองต่อเพจ ไม่ได้รับรองลิขสิทธิ์ ความปลอดภัย หรือคุณภาพสื่อ ในทำนองเดียวกัน ส่วนหัวที่หายไปไม่ได้พิสูจน์ว่า URL ใช้งานไม่ได้ หมายความว่าสคริปต์ข้ามต้นทางนี้ไม่ได้รับอนุญาตให้อ่านสิ่งที่เซิร์ฟเวอร์ส่งคืน ผู้ดูแลระบบโฮสต์ควรทดสอบแหล่งที่มาของการร้องขอและวิธีการที่พวกเขาตั้งใจจะสนับสนุน แทนที่จะเพิ่มส่วนหัวที่อนุญาตแบบสุ่มสี่สุ่มห้าให้กับเนมสเปซการจัดเก็บข้อมูลทั้งหมด
การอ่านข้ามต้นทางที่ถูกบล็อก และเหตุใดสคริปต์จึงไม่ได้รับการตอบกลับที่บันทึกได้
ตัวดาวน์โหลดใช้การดึงข้อมูลโหมด CORS ธรรมดามากกว่า `no-cors` ในการอ่านแบบข้ามต้นทางที่ถูกปฏิเสธ การดึงข้อมูลจะถูกปฏิเสธและโค้ดของแอปพลิเคชันจะไม่ได้รับทั้งส่วนหัวและเนื้อความที่ใช้งานได้ เครื่องมือรายงานหมวดหมู่ `CORS_OR_NETWORK` ที่รวมกัน เนื่องจากเบราว์เซอร์ตั้งใจไม่เปิดเผยรายละเอียดเพียงพอที่จะแยกแยะ CORS จากความล้มเหลวในการขนส่งทุกครั้ง
การตอบสนองแบบทึบเป็นของคำขอ `no-cors` ที่ชัดเจน แต่โหมดนั้นไม่สามารถแก้ปัญหานี้ได้: JavaScript ไม่สามารถตรวจสอบเนื้อหาทึบแสงและเปลี่ยนให้เป็น Blob ที่ต้องการได้ การใช้งานจึงล้มเหลวโดยสุจริตแทนที่จะได้รับคำตอบที่อ่านไม่ได้และแสร้งทำเป็นว่าสามารถบันทึกได้ เนื่องจากแอปพลิเคชันไม่เคยได้รับไบต์ที่ซ่อนอยู่ จึงไม่สามารถคำนวณความคืบหน้าตามความเป็นจริง อนุมานชื่อไฟล์จากส่วนหัวที่ได้รับการป้องกัน หรือสร้างวัตถุที่มีประโยชน์ URL จากสิ่งเหล่านี้ได้
ตัวอย่างการทำงาน: การอ่านคำขอที่ล้มเหลวในแผงเครือข่าย - ตรวจพบส่วนหัวที่หายไปและยืนยันว่าไม่มีการติดต่อเซิร์ฟเวอร์รีเลย์
เปิดแผงเครือข่าย เก็บบันทึก และกดตรวจสอบลิงก์หนึ่งครั้ง แถว HEAD ที่พยายามระบุปลายทางและอาจแสดงการวินิจฉัย CORS ของเบราว์เซอร์ ตรวจสอบส่วนหัวของการตอบกลับ หากมี การไม่มีส่วนหัวที่อนุญาตจะอธิบายว่าทำไมโค้ดของหน้าจึงไม่ได้รับขนาดที่โฆษณาหรือประเภท MIME
การตรวจสอบที่ล้มเหลวเป็นหลักฐานอยู่แล้วว่ามีการพยายามร้องขอจริง ไม่มีแถว ToolAcre API ที่มีการวาง URL และไม่มีคำขอส่งต่อครั้งที่สอง หากโฮสต์อนุญาตให้ HEAD ทำงานได้ไม่ดี การดาวน์โหลดอาจยังคงทำงานแตกต่างออกไปเนื่องจากใช้ GET แต่ไม่มีเส้นทางใดที่สลับสถาปัตยกรรมโดยไม่โต้ตอบ ข้อความคอนโซลแตกต่างกันไปในแต่ละเบราว์เซอร์ ดังนั้นควรเก็บหลักฐานแถวและส่วนหัวที่ล้มเหลว แทนที่จะขึ้นอยู่กับถ้อยคำของผู้ขายรายหนึ่งสำหรับรายงานการปฏิบัติงาน
เหตุใดเครื่องมือจึงไม่เปลี่ยนเส้นทาง — พร็อกซีหมายถึงการส่งลิงก์ของคุณไปยังเซิร์ฟเวอร์ ซึ่งเป็นสิ่งที่เครื่องมือสัญญาว่าจะไม่ทำ
พร็อกซีสามารถดึงไฟล์ฝั่งเซิร์ฟเวอร์และส่งคืนจากจุดสิ้นสุดที่มีต้นทางเดียวกัน โดยหลีกเลี่ยงการอ่านแบบข้ามต้นทางของเบราว์เซอร์ นอกจากนี้ยังจะเปิดเผยลิงก์และทุกไบต์ที่ส่งต่อไปยังโอเปอเรเตอร์นั้น ต้องใช้แบนด์วิธ และสร้างพื้นผิวการดึงข้อมูลตามอำเภอใจ ToolAcre จงใจไม่มีจุดสิ้นสุดดังกล่าว
ทางเลือกสำรองที่แนะนำโดยอินเทอร์เฟซคือลิงก์บันทึกแบบเนทีฟของเบราว์เซอร์เป็นการดำเนินการ หากมี นั่นคือการนำทางหรือการจัดการการดาวน์โหลดมากกว่าการอ่านสคริปต์หน้า คำแนะนำนี้ไม่ได้ทำให้นโยบายโฮสต์อ่อนลง ตรวจสอบสิทธิ์ผู้เยี่ยมชม หรือเปลี่ยนสตรีมที่ได้รับการป้องกันให้เป็นไฟล์โดยตรง การปฏิเสธทางสถาปัตยกรรมดังกล่าวยังป้องกันไม่ให้ ToolAcre สะสมสำเนา บันทึกการเข้าถึง หรือสิทธิ์ในการดึงข้อมูลขาออกเพียงเพื่อเปลี่ยนการปฏิเสธของเบราว์เซอร์ให้ประสบความสำเร็จอย่างเห็นได้ชัด
สิ่งนี้ไม่ครอบคลุม — CORS ไม่เหมือนกับ 403 วอลล์การเข้าสู่ระบบ หรือ URL ที่ลงนามแล้วหมดอายุ
ความล้มเหลว CORS ไม่ใช่ HTTP 403 แม้ว่าจะสามารถหยุดเวิร์กโฟลว์ได้ก็ตาม 403 คือสถานะการตอบกลับที่โฮสต์เลือก ลายเซ็นที่หมดอายุอาจทำให้เกิดสิ่งหนึ่งได้ วอลล์การเข้าสู่ระบบจำเป็นต้องมีข้อมูลประจำตัวที่เครื่องมือนี้ละเว้น เครือข่ายขัดข้อง DNS ล้มเหลว และปัญหาใบรับรองสามารถแชร์การปฏิเสธการดึงข้อมูลทั่วไปของเบราว์เซอร์ได้
การวินิจฉัยจึงควรใช้แผงเครือข่ายและคอนโซลร่วมกันแทนที่จะถือว่าความล้มเหลวทั้งหมดเป็นส่วนหัวที่ขาดหายไป ToolAcre รายงานสถานะ HTTP ที่ทราบเมื่อมีการตอบกลับที่อ่านได้มาถึง แต่ปฏิเสธที่จะคาดเดาเมื่อเบราว์เซอร์ให้เฉพาะข้อยกเว้นรูปแบบการขนส่งเท่านั้น การแยกหมวดหมู่เหล่านี้ออกจากกันจะทำให้การแก้ไขถูกต้อง: กำหนดค่า CORS สำหรับวัตถุสาธารณะที่ได้รับอนุญาต รีเฟรชลิงก์ที่หมดอายุ ลงชื่อเข้าใช้ผ่านผู้ให้บริการ หรือแก้ไขการเชื่อมต่อ
ประเด็นสำคัญ: CORS เป็นการตัดสินใจฝั่งโฮสต์ — วิธีที่ Direct Media Downloader รายงานอย่างตรงไปตรงมา แทนที่จะถอยกลับไปยังเซิร์ฟเวอร์อย่างเงียบๆ
CORS ถูกควบคุมที่โฮสต์สื่อ โปรแกรมดาวน์โหลดเฉพาะเบราว์เซอร์สามารถปฏิบัติตามตัวเลือกนั้น อธิบาย และหยุดได้ ไม่สามารถแทนที่ตัวเลือกจากรหัสไคลเอ็นต์ได้ ขอบเขตนี้ไม่สะดวกอย่างแน่นอน เนื่องจากจะป้องกันไม่ให้เพจที่กำหนดเองกลายเป็นโปรแกรมอ่านข้ามไซต์แบบสากล
ใช้การควบคุมการดาวน์โหลดที่โฮสต์ให้มา ขอไฟล์ที่ได้รับอนุญาตที่เปิดใช้งาน CORS หรือใช้ลิงก์บันทึกดั้งเดิมตามความเหมาะสม Direct Media Downloader รักษาคำมั่นสัญญาด้วยการเปิดเผยการปฏิเสธและรักษาเส้นทางโดยตรงจากเบราว์เซอร์ไปยังโฮสต์ ไม่ใช่โดยการซ่อนเซิร์ฟเวอร์ไว้ด้านหลังปุ่มที่ประสบความสำเร็จมากกว่า ผลลัพธ์ที่ประสบความสำเร็จจึงต้องมาจากโฮสต์ที่ให้ความร่วมมือหรือโปรแกรมเบราว์เซอร์อื่นที่ถูกต้องตามกฎหมาย โดยจะต้องไม่ระงับข้อความแสดงข้อผิดพลาดในขณะที่ยังคงการอ่านที่ถูกปฏิเสธเหมือนเดิม