Video và phụ đề · Trình tải xuống hình thu nhỏ & Trình xem siêu dữ liệu của YouTube
Cách trình duyệt lưu hình ảnh có nguồn gốc chéo: tìm nạp, URL Blob và tải xuống
· Cách thức hoạt động
youtube javascript cors
Việc lưu hình ảnh từ một miền khác khó hơn so với liên kết có thuộc tính tải xuống. Bài đăng này giải thích lý do tại sao thuộc tính này bị bỏ qua đối với các URL có nguồn gốc chéo, cách tìm nạp và URL Blob giải quyết vấn đề đó cũng như CORS phải làm gì với thuộc tính đó.
Thuộc tính tải xuống đã mở hình ảnh thay vì lưu nó - tính năng bắt nguồn gốc chéo
Một mỏ neo trỏ vào một nguồn gốc khác có thể điều hướng đến một hình ảnh thay vì tôn trọng tên tệp mong muốn. Trình tải xuống đáng tin cậy cần các byte có thể đọc được theo quy tắc nguồn gốc chéo của trình duyệt chứ không chỉ đơn thuần là thuộc tính tải xuống trên điều khiển từ xa URL. Quá trình kiểm tra trực quan rất đơn giản: việc lưu JPEG đã được xác minh sẽ tạo tên tệp ToolAcre mà không cần thêm yêu cầu i.ytimg.com khác.
ToolAcre đã tìm nạp từng ứng cử viên JPEG để xác định xem ứng viên đó có thật hay không. Giữ Blob thành công có nghĩa là lần tải xuống sau có thể sử dụng cùng các byte đó thay vì đưa ra yêu cầu mạng thứ hai. Việc sử dụng lại đó giữ cho tệp đã lưu giống hệt với hình ảnh có kích thước và trạng thái giữ chỗ đã được kiểm tra ngay trước đó.
Tại sao trình duyệt bỏ qua việc tải xuống từ nguồn khác - một quyết định bảo mật và hậu quả của nó
Các trình duyệt hạn chế tải xuống từ nhiều nguồn gốc vì một trang không được tự động đổi tên và lưu các tài nguyên từ xa tùy ý. Hành vi phụ thuộc vào phản hồi từ xa và mối quan hệ nguồn gốc, do đó, một liên kết đơn giản không phải là cách lưu tệp chung API. Chỉ riêng thuộc tính `download` không thể đảm bảo rằng hình ảnh YouTube từ xa sẽ được lưu dưới tên cục bộ được yêu cầu.
Thiết kế an toàn hơn là rõ ràng: yêu cầu hình ảnh công khai được tiết lộ, xác minh phản hồi và xây dựng đối tượng do trình duyệt quản lý URL chỉ dành cho dữ liệu mà trang được phép đọc. Nếu CORS chặn quyền truy cập, JavaScript không có Blob để xác thực hoặc lưu, mặc dù việc điều hướng trực tiếp đến địa chỉ hình ảnh vẫn có thể hiển thị địa chỉ đó trong một tab.
Lộ trình tìm nạp và Blob — tìm nạp các byte hình ảnh, gói chúng trong Blob và tạo một blob có cùng nguồn gốc: URL
Đối với JPEG, thăm dòThumbnail thực hiện CORS GET ẩn danh, chuyển đổi phản hồi thành công thành Blob và giải mã các thứ nguyên. Một Blob có thể sử dụng được sẽ được giữ lại trên kết quả, trong khi phần giữ chỗ bị loại bỏ nên chúng không thể giả dạng thành các bản tải xuống. Do đó, nút tải xuống biểu thị các byte đã được xác minh trong bộ nhớ chứ không phải độ tin cậy được suy ra từ tên tệp hoặc chỉ HTTP 200.
Sau đó, một đối tượng URL có thể đại diện cho Blob trong bộ nhớ đó cho hành động lưu cục bộ. Điều này không làm cho việc tìm nạp ban đầu trở nên cục bộ; Google đã cung cấp byte trực tiếp cho trình duyệt sau khi Tìm nạp. Địa chỉ `blob:` là một trình điều khiển tạm thời của trình duyệt cho nội dung phản hồi đó, không phải là bản sao được lưu trữ bởi ToolAcre hoặc quyền mới được cấp đối với hình ảnh nguồn.
CORS cho phép JPEG tải xuống tìm nạp và Blob; WebP vẫn chỉ ở dạng liên kết
Phác thảo ngụ ý CORS là một cổng chung nhưng hành vi được vận chuyển có định dạng cụ thể. JPEG tải xuống tìm nạp và Blob hoạt động; đường dẫn /vi_webp/ được cung cấp mà không có tiêu đề gốc bắt buộc, vì vậy ToolAcre chỉ cung cấp WebP dưới dạng liên kết. Người đánh giá nên kiểm tra riêng hai họ đường dẫn thay vì khái quát hóa tiêu đề phản hồi JPEG cho mọi định dạng hình thu nhỏ.
Giới hạn đó không được khắc phục bằng cách thay đổi JavaScript hoặc thử lại thông qua ToolAcre vì không tồn tại proxy ToolAcre. Trình chặn, kết nối ngoại tuyến hoặc proxy công ty cũng có thể dừng tài nguyên từ xa. Quyền truy cập WebP chỉ liên kết phản ánh chính xác những gì máy chủ từ xa cho phép trang thực hiện: trỏ vào tệp nhưng không đọc byte của nó để đóng gói lại.
Đặt tên tệp đã lưu - lý do người tải xuống nên đặt tên tệp theo ID video và kích thước để có thể nhận dạng tệp
Tên JPEG đã tải xuống sử dụng youtube-VIDEO_ID-VARIANT.jpg. Cả mã định danh và biến thể đều đến từ bảng chữ cái đã được xác thực, ngăn không cho dấu phân cách đường dẫn hoặc ký tự điều khiển tùy ý nhập tên tệp được đề xuất. Do đó, việc lưu `maxresdefault` và `hq2` từ một lần tra cứu sẽ tạo ra các tên riêng biệt, có thể dự đoán được và có thể khớp lại với các hàng kết quả của chúng.
Tên tệp mô tả sẽ duy trì nguồn gốc khi có nhiều kích cỡ nằm trong một thư mục. Nó cũng tránh giả vờ tiêu đề siêu dữ liệu là tên hệ thống tệp an toàn vì tiêu đề có thể chứa dấu câu và có thể thay đổi độc lập. ID bất biến xác định tham chiếu video, trong khi hậu tố biến thể giải thích ứng cử viên hình ảnh được xuất bản nào đã cung cấp byte.
Ví dụ hoạt động: lưu hai kích thước hình thu nhỏ cho một video - chuỗi yêu cầu và tệp kết quả
Tìm nạp một video công khai và chọn hai biến thể JPEG có sẵn. Mỗi cái được yêu cầu một lần trong quá trình thăm dò, được giải mã để chứng minh các kích thước và được giữ lại dưới dạng Blob; nhấp vào lưu sẽ sử dụng lại kết quả đó và tạo ra hai tệp được đặt tên rõ ràng. Khi DevTools mở, việc không có yêu cầu hình ảnh thứ hai xác nhận rằng bản lưu đến từ phản hồi được giữ lại chứ không phải từ bản tải xuống từ xa mới.
Nếu một ứng viên trả về HTTP 200 dưới dạng phần giữ chỗ 120×90, công cụ sẽ đánh dấu phần đó bị thiếu và không lưu trữ Blob có thể tải xuống. 404, lỗi khác hoặc phản hồi không thể giải mã được cũng được báo cáo thay vì được lưu. Việc tắt hành động lưu đối với các hàng này sẽ ngăn phần giữ chỗ chung hoặc phần tải trọng lỗi vào thư mục nội dung dưới một tên biến thể thuyết phục.
Điều này không bao gồm những gì - tải xuống hàng loạt trên nhiều video và các máy chủ chặn việc đọc nhiều nguồn gốc
Không có chế độ hàng loạt trên nhiều video và không có chế độ bỏ qua đối với các máy chủ cấm đọc nhiều nguồn gốc. Sản phẩm xử lý một video mỗi lần và tự giới hạn ở hai dịch vụ được tiết lộ của Google. Mỗi Blob được giữ lại thuộc về tập kết quả hiện tại, do đó, nó không được coi là bộ nhớ đệm lâu bền cho các video sau này hoặc các phiên bản trong tương lai của cùng một hình thu nhỏ.
Nó cũng không truy xuất video hoặc âm thanh và các bản ghi riêng tư, bị xóa hoặc bị giới hạn độ tuổi vẫn không khả dụng. Cơ chế lưu tệp công khai không thể mở rộng quyền truy cập hoặc tạo ra hình thu nhỏ vắng mặt. Quá trình tạo Blob chỉ bắt đầu sau khi các byte hình ảnh có thể đọc được đến, do đó, nó không đưa ra lộ trình nào xung quanh phản hồi bị từ chối hoặc một biến thể chưa được xuất bản.
JPEG tìm nạp, sử dụng lại Blob và tải xuống—với WebP được giữ làm liên kết
Trước khi Tìm nạp, phân tích cú pháp URL là cục bộ. Sau đó, mỗi thăm dò JPEG và yêu cầu oEmbed chuẩn sẽ đi thẳng từ trình duyệt với thông tin xác thực bị bỏ qua, không có chuyển hướng giới thiệu, không lưu trữ và chuyển hướng được theo dõi; Google nhìn thấy tiêu đề Origin. Ngày tải xuống quan trọng một cách độc lập vì cả đối tượng URL lẫn đường dẫn nguồn có thể dự đoán đều không giữ lại bản sửa đổi hình thu nhỏ trước đó.
Kết quả là không đối xứng có chủ ý: JPEG byte đã được xác minh có thể trở thành bản tải xuống Blob, trong khi năm URL người đăng WebP vẫn là liên kết bên ngoài vì phản hồi của chúng thiếu quyền CORS. Giao diện phải bảo toàn ranh giới trung thực đó. Người dùng có thể mở hoặc sao chép địa chỉ WebP nhưng ToolAcre không thể hứa hẹn đổi tên tệp WebP cục bộ từ byte mà trình duyệt cấm nó đọc.