วิดีโอและคำบรรยาย · โปรแกรมดาวน์โหลดภาพขนาดย่อของ YouTube และโปรแกรมดูข้อมูลเมตา
วิธีที่เบราว์เซอร์บันทึกรูปภาพข้ามต้นทาง: ดึงข้อมูล Blob URL และดาวน์โหลด
· มันทำงานอย่างไร
youtube javascript cors
การบันทึกรูปภาพจากโดเมนอื่นนั้นยากกว่าลิงก์ที่มีแอตทริบิวต์การดาวน์โหลด โพสต์นี้อธิบายว่าทำไมแอตทริบิวต์จึงถูกละเว้นสำหรับ URL แบบข้ามต้นทาง วิธีแก้ไข fetch และ Blob URL และ CORS เกี่ยวข้องกับคุณลักษณะนี้อย่างไร
แอตทริบิวต์การดาวน์โหลดจะเปิดรูปภาพแทนที่จะบันทึก ซึ่งเป็นการข้ามแหล่งที่มา
จุดยึดที่ชี้ไปที่จุดกำเนิดอื่นอาจนำทางไปยังรูปภาพแทนที่จะให้เกียรติชื่อไฟล์ที่ต้องการ โปรแกรมดาวน์โหลดที่เชื่อถือได้ต้องมีไบต์ที่สามารถอ่านได้ภายใต้กฎข้ามต้นทางของเบราว์เซอร์ ไม่ใช่เพียงแอตทริบิวต์การดาวน์โหลดบน URL ระยะไกล การทดสอบที่มองเห็นได้นั้นตรงไปตรงมา: การบันทึก JPEG ที่ได้รับการยืนยันควรสร้างชื่อไฟล์ ToolAcre โดยไม่ต้องเพิ่มคำขอ i.ytimg.com อีก
ToolAcre ดึงข้อมูลผู้สมัคร JPEG แต่ละคนแล้วเพื่อพิจารณาว่าเป็นของจริงหรือไม่ การรักษา Blob ให้สำเร็จหมายความว่าการดาวน์โหลดในภายหลังสามารถใช้ไบต์เดียวกันเหล่านั้นแทนการออกคำขอเครือข่ายที่สอง การใช้ซ้ำจะทำให้ไฟล์ที่บันทึกไว้เหมือนกับรูปภาพที่มีการตรวจสอบขนาดและสถานะตัวยึดตำแหน่งก่อนหน้านี้
เหตุใดเบราว์เซอร์จึงเพิกเฉยต่อการดาวน์โหลดจากแหล่งอื่น — การตัดสินใจด้านความปลอดภัยและผลที่ตามมา
เบราว์เซอร์จำกัดการดาวน์โหลดแบบข้ามต้นทาง เนื่องจากเพจไม่ควรเปลี่ยนชื่อและบันทึกทรัพยากรระยะไกลโดยพลการ ลักษณะการทำงานขึ้นอยู่กับการตอบสนองระยะไกลและความสัมพันธ์ต้นทาง ดังนั้นลิงก์แบบธรรมดาจึงไม่ใช่การบันทึกไฟล์สากล API แอตทริบิวต์ `download` เพียงอย่างเดียวไม่สามารถรับประกันได้ว่ารูปภาพ YouTube ระยะไกลจะถูกบันทึกภายใต้ชื่อท้องถิ่นที่ร้องขอ
การออกแบบที่ปลอดภัยกว่านั้นมีความชัดเจน: ขอรูปภาพสาธารณะที่เปิดเผย ตรวจสอบการตอบสนอง และสร้างออบเจ็กต์ที่จัดการโดยเบราว์เซอร์ URL สำหรับข้อมูลที่เพจได้รับอนุญาตให้อ่านเท่านั้น หาก CORS บล็อกการเข้าถึง JavaScript จะไม่มี Blob เพื่อตรวจสอบหรือบันทึก แม้ว่าการนำทางโดยตรงไปยังที่อยู่รูปภาพอาจยังแสดงในแท็บก็ตาม
เส้นทาง fetch-and-Blob — ดึงข้อมูลไบต์ของรูปภาพ ล้อมไว้ใน Blob และสร้าง Blob ที่มีต้นกำเนิดเดียวกัน: URL
สำหรับ JPEG นั้น probeThumbnail จะดำเนินการ CORS โดยไม่ระบุชื่อ GET แปลงการตอบกลับที่สำเร็จเป็น Blob และถอดรหัสมิติ Blob ที่ใช้งานได้จะยังคงอยู่ในผลลัพธ์ ในขณะที่ตัวยึดตำแหน่งจะถูกละทิ้ง ดังนั้นจึงไม่สามารถปลอมแปลงเป็นการดาวน์โหลดได้ ปุ่มดาวน์โหลดจึงแสดงถึงไบต์ที่ได้รับการยืนยันในหน่วยความจำ ไม่ใช่ความเชื่อมั่นที่อนุมานจากชื่อไฟล์หรือ HTTP 200 เพียงอย่างเดียว
จากนั้นอ็อบเจ็กต์ URL จะสามารถแสดงถึง Blob ในหน่วยความจำนั้นสำหรับการดำเนินการบันทึกในเครื่อง สิ่งนี้ไม่ได้ทำให้การดึงข้อมูลต้นฉบับในเครื่อง Google จัดเตรียมไบต์ให้กับเบราว์เซอร์โดยตรงหลังจากการดึงข้อมูล ที่อยู่ `blob:` เป็นตัวจัดการเบราว์เซอร์ชั่วคราวสำหรับเนื้อหาการตอบสนองนั้น ไม่ใช่มิเรอร์ที่โฮสต์โดย ToolAcre หรือสิทธิ์ที่ได้รับใหม่ในอิมเมจต้นฉบับ
CORS อนุญาตให้ JPEG ดึงข้อมูลและดาวน์โหลด Blob; WebP ยังคงเป็นลิงก์เท่านั้น
โครงร่างที่บอกเป็นนัยว่า CORS นั้นเป็นเกททั่วไปหนึ่งเกท แต่ลักษณะการทำงานที่จัดส่งนั้นมีความเฉพาะเจาะจงกับรูปแบบ JPEG การดาวน์โหลด fetch-and-Blob ใช้งานได้ เส้นทาง /vi_webp/ ให้บริการโดยไม่มีส่วนหัว cross-origin ที่จำเป็น ดังนั้น ToolAcre จึงจัดเตรียม WebP เป็นลิงก์เท่านั้น ผู้ตรวจสอบควรทดสอบกลุ่มเส้นทางทั้งสองแยกกัน แทนที่จะสรุปส่วนหัวการตอบกลับ JPEG ให้กับทุกรูปแบบภาพขนาดย่อ
ข้อจำกัดดังกล่าวไม่ได้รับการซ่อมแซมโดยการเปลี่ยน JavaScript หรือลองอีกครั้งผ่าน ToolAcre เนื่องจากไม่มีพร็อกซี ToolAcre อยู่ ตัวบล็อก การเชื่อมต่อออฟไลน์ หรือพร็อกซีขององค์กรสามารถหยุดทรัพยากรระยะไกลได้เช่นกัน การเข้าถึง WebP แบบลิงก์เท่านั้น สะท้อนถึงสิ่งที่เซิร์ฟเวอร์ระยะไกลอนุญาตให้เพจทำได้อย่างแม่นยำ นั่นคือ ชี้ไปที่ไฟล์ แต่ไม่ได้อ่านไบต์ของไฟล์เพื่อบรรจุใหม่
การตั้งชื่อไฟล์ที่บันทึกไว้ — เหตุใดผู้ดาวน์โหลดจึงควรตั้งชื่อไฟล์ตามรหัสวิดีโอและขนาดเพื่อให้สามารถระบุไฟล์ได้
ดาวน์โหลดชื่อ JPEG ใช้ youtube-VIDEO_ID-VARIANT.jpg ทั้งตัวระบุและตัวแปรมาจากตัวอักษรที่ผ่านการตรวจสอบแล้ว ป้องกันไม่ให้ตัวคั่นพาธหรืออักขระควบคุมที่กำหนดเองป้อนชื่อไฟล์ที่แนะนำ การบันทึก `maxresdefault` และ `hq2` จากการค้นหาครั้งเดียวจึงควรสร้างชื่อที่ชัดเจนและคาดเดาได้ ซึ่งสามารถจับคู่กลับไปยังแถวผลลัพธ์ได้
ชื่อไฟล์ที่สื่อความหมายจะคงที่มาเมื่อมีหลายขนาดอยู่ในโฟลเดอร์เดียว นอกจากนี้ยังหลีกเลี่ยงการแสร้งทำเป็นว่าชื่อข้อมูลเมตาเป็นชื่อระบบไฟล์ที่ปลอดภัย เนื่องจากชื่ออาจมีเครื่องหมายวรรคตอนและสามารถเปลี่ยนแปลงได้อย่างอิสระ รหัสที่ไม่เปลี่ยนรูปจะระบุการอ้างอิงวิดีโอ ในขณะที่ส่วนต่อท้ายของรูปแบบจะอธิบายว่าตัวเลือกรูปภาพที่เผยแพร่ใดที่ให้ไบต์มา
ตัวอย่างการทำงาน: บันทึกภาพขนาดย่อสองขนาดสำหรับวิดีโอเดียว — ลำดับคำขอและไฟล์ที่เป็นผล
เรียกวิดีโอสาธารณะหนึ่งรายการและเลือกรูปแบบ JPEG ที่มีให้เลือกสองรายการ แต่ละรายการได้รับการร้องขอหนึ่งครั้งในระหว่างการสอบสวน ถอดรหัสเพื่อพิสูจน์มิติและคงไว้เป็น Blob การคลิกบันทึกควรใช้ผลลัพธ์นั้นซ้ำและสร้างไฟล์ที่มีชื่อชัดเจนสองไฟล์ เมื่อเปิด DevTools ไว้ การไม่มีคำขอรูปภาพที่สองเป็นการยืนยันว่าการบันทึกมาจากการตอบสนองที่เก็บไว้ ไม่ใช่การดาวน์โหลดจากระยะไกลครั้งใหม่
หากผู้สมัครรายหนึ่งส่งคืน HTTP 200 เป็นตัวยึดตำแหน่ง 120×90 เครื่องมือจะทำเครื่องหมายว่าไม่มีและไม่มี Blob ที่ดาวน์โหลดได้ 404 ข้อผิดพลาดอื่นๆ หรือการตอบสนองที่ไม่สามารถถอดรหัสได้จะถูกรายงานเช่นเดียวกันแทนที่จะบันทึก การปิดใช้งานการดำเนินการบันทึกสำหรับแถวเหล่านี้จะป้องกันไม่ให้ตัวยึดตำแหน่งทั่วไปหรือเพย์โหลดข้อผิดพลาดเข้าสู่โฟลเดอร์สินทรัพย์ภายใต้ชื่อตัวแปรที่น่าเชื่อถือ
สิ่งนี้ไม่ครอบคลุมถึง — การดาวน์โหลดเป็นชุดในวิดีโอจำนวนมาก และโฮสต์ที่บล็อกการอ่านแบบข้ามต้นทาง
ไม่มีโหมดแบทช์ในวิดีโอจำนวนมากและไม่มีการข้ามสำหรับโฮสต์ที่ห้ามการอ่านแบบข้ามต้นทาง ผลิตภัณฑ์จัดการวิดีโอครั้งละหนึ่งรายการและจำกัดตัวเองไว้เฉพาะบริการของ Google สองรายการที่เปิดเผยเท่านั้น Blob ที่เก็บรักษาไว้แต่ละรายการเป็นของชุดผลลัพธ์ปัจจุบัน ดังนั้นจึงไม่ควรถือเป็นแคชที่คงทนสำหรับวิดีโอต่อๆ ไปหรือภาพขนาดย่อเดียวกันในเวอร์ชันในอนาคต
นอกจากนี้ยังไม่ดึงข้อมูลวิดีโอหรือเสียง และบันทึกส่วนตัว ลบออก หรือจำกัดอายุยังคงไม่สามารถใช้งานได้ กลไกการบันทึกไฟล์สาธารณะไม่สามารถขยายสิทธิ์การเข้าถึงหรือสร้างภาพขนาดย่อที่หายไปได้ การสร้าง Blob เริ่มต้นหลังจากไบต์ภาพที่อ่านได้มาถึงแล้วเท่านั้น ดังนั้นจึงไม่มีเส้นทางรอบการตอบกลับที่ถูกปฏิเสธหรือรูปแบบที่ยังไม่ได้เผยแพร่
JPEG ดึงข้อมูล ใช้ Blob ซ้ำ และดาวน์โหลด โดยที่ WebP เก็บไว้เป็นลิงก์
ก่อนที่จะดึงข้อมูล การแยกวิเคราะห์ URL อยู่ในเครื่อง หลังจากนั้น แต่ละโพรบ JPEG และคำขอ oEmbed ที่เป็นที่ยอมรับจะส่งตรงจากเบราว์เซอร์โดยละเว้นข้อมูลประจำตัว ไม่มีผู้อ้างอิง ไม่มีการจัดเก็บ และการเปลี่ยนเส้นทางที่ติดตาม Google เห็นส่วนหัว Origin วันที่ดาวน์โหลดที่สำคัญโดยแยกจากกัน เนื่องจากทั้งออบเจ็กต์ URL และเส้นทางแหล่งที่มาที่คาดเดาได้จะไม่รักษาการแก้ไขภาพขนาดย่อก่อนหน้านี้
ผลลัพธ์ที่ได้คือจงใจไม่สมมาตร: ไบต์ JPEG ที่ได้รับการยืนยันสามารถกลายเป็นการดาวน์โหลด Blob ได้ ในขณะที่ URL โปสเตอร์ WebP ห้ารายการยังคงเป็นลิงก์ภายนอกเนื่องจากการตอบกลับขาดสิทธิ์ CORS อินเทอร์เฟซควรรักษาขอบเขตที่ซื่อสัตย์นั้นไว้ ผู้ใช้สามารถเปิดหรือคัดลอกที่อยู่ WebP ได้ แต่ ToolAcre ไม่สามารถรับประกันไฟล์ WebP ในเครื่องที่ถูกเปลี่ยนชื่อจากไบต์ที่เบราว์เซอร์ห้ามไม่ให้อ่าน