Yêu cầu preflight là gì? Giải thích các kiểm tra CORS OPTIONS

Yêu cầu preflight là gì?

Yêu cầu preflight là một kiểm tra CORS tự động trong đó trình duyệt gửi yêu cầu OPTIONS trước một số yêu cầu cross-origin nhất định. Yêu cầu preflight xác định nguồn gốc của caller, phương thức dự kiến, và tên trường yêu cầu không nằm trong danh sách an toàn. Phản hồi của máy chủ cho biết liệu trình duyệt có thể gửi yêu cầu thực tế hay không; yêu cầu preflight không thực thi hoạt động ứng dụng đã dự định đó.

Định nghĩa hữu ích bao gồm cả cơ chế và ranh giới của nó. Yêu cầu Preflight ảnh hưởng đến một phần cụ thể của một giao dịch, trong khi các trách nhiệm liền kề vẫn thuộc về HTTP, trình duyệt, phương tiện vận chuyển được chọn, ứng dụng, hoặc mô hình dữ liệu của máy chủ. Giữ các lớp đó tách biệt giúp báo cáo lỗi có thể tái sản xuất và ngăn chặn thay đổi cấu hình bị nhầm lẫn với quyết định kiểm soát truy cập.

Đối với các nhà phát triển API, câu hỏi đầu tiên là ai tạo ra giá trị hoặc hành vi. Câu hỏi tiếp theo là ai diễn giải nó. Câu hỏi cuối cùng là kết quả observable nào chứng minh rằng việc diễn giải thành công. Ba câu trả lời đó biến một thuật ngữ từ điển thành một hợp đồng giao diện có thể thử nghiệm.

Kiểm tra OPTIONS trước yêu cầu thực tế

Trình duyệt phân loại một việc lấy cross-origin dựa trên phương thức của nó, các trường do tác giả kiểm soát, và loại nội dung. Nếu yêu cầu nằm ngoài hình dạng đã được liệt kê an toàn CORS, trình duyệt tạo một yêu cầu OPTIONS đến URL mục tiêu thay vì gửi phương thức ứng dụng ngay lập tức.

Nguồn gốc xác định trang gọi. Access-Control-Request-Method đặt tên cho phương thức dự định, và Access-Control-Request-Headers liệt kê các tên trường yêu cầu không nằm trong danh sách an toàn có liên quan. Yêu cầu preflight không mang theo nội dung yêu cầu thực tế, và các quy tắc Fetch thông thường cho biết yêu cầu preflight CORS loại trừ thông tin xác thực.

Máy chủ hoặc cổng trả lại Access-Control-Allow-Origin cộng với phương thức và quyền trường bao trùm giao dịch dự kiến. Nó cũng có thể trả lại Access-Control-Max-Age để trình duyệt có thể lưu cache một kết quả preflight thành công trong giới hạn thực hiện.

Chỉ sau khi chính sách khớp thì trình duyệt mới gửi yêu cầu thực tế. Phản hồi thứ hai cũng phải mang theo quyền CORS thích hợp. Chuyển qua OPTIONS nhưng bỏ qua các trường trong phản hồi thực tế vẫn tạo ra một lỗi có thể thấy từ trình duyệt.

Đọc một cặp yêu cầu preflight

Các thuật ngữ sau đây tách các thành phần thường bị gộp thành một nhãn duy nhất. Đọc chúng như các giao diện giữa các bên tham gia hơn là như trang trí trong một bản theo dõi mạng.

Tại sao yêu cầu preflight quan trọng trong việc thu thập dữ liệu web

Yêu cầu preflight có thể thay đổi những gì byte đến, cách những byte đó được diễn giải, hoặc liệu mã của trình duyệt có thể quan sát kết quả hay không. Một quy trình thu thập nên xác định hiệu ứng đó trước khi thay đổi công cụ. Ghi lại URL được yêu cầu, URL cuối cùng, trạng thái phản hồi, loại đại diện, các trường giao thức có liên quan, và một dấu hiệu nội dung dự kiến. Ghi chép gọn gàng đó phân biệt một trang chính xác khỏi một tin nhắn truy cập, màn hình đồng ý, mục tiêu chuyển hướng, shell ứng dụng trống, hoặc mã hóa không tương thích.

HTTP trực tiếp là con đường thu thập đơn giản nhất khi dữ liệu yêu cầu tồn tại trong một phản hồi được tạo từ máy chủ mở. Một trình duyệt trở nên có liên quan khi nội dung được phê duyệt phụ thuộc vào việc thực thi JavaScript, trạng thái quản lý bởi trình duyệt, điều hướng, hoặc chính sách bảo mật của trình duyệt. Hai con đường không nên ép buộc phải trông giống nhau: các trình duyệt quản lý cookie, nén, chuyển hướng, CORS, và lưu trữ theo quy tắc nền tảng, trong khi một khách hàng trực tiếp tiết lộ một tập hợp khác các mặc định.

Liên tục phiên rất quan trọng bất cứ khi nào một phản hồi thiết lập trạng thái cho yêu cầu tiếp theo. Giữ một chuỗi được ủy quyền bên trong một ngữ cảnh cliente giới hạn, bảo vệ ngôn ngữ và nguồn gốc mạng cần thiết, và tránh trộn lẫn trạng thái từ các công việc không liên quan. Một proxy thay đổi nguồn gốc mạng; nó không tái tạo tiêu đề, giải mã các đại diện, thực thi các kịch bản, hoặc cấp quyền truy cập vào nội dung bị hạn chế.

Phân tích chỉ bắt đầu sau khi xác thực đại diện. Xác nhận máy chủ cuối cùng, danh tính chính xác nếu có, loại phương tiện, trạng thái giải mã, và dấu hiệu kinh doanh cần thiết trước khi trích xuất các trường. Thứ tự này ngăn chặn một trình phân tích chuyển đổi một tài liệu lỗi thành các bản ghi trống xuất hiện thành công về mặt kỹ thuật.

Các trung gian xứng đáng được chú ý đặc biệt. Một mạng lưới phân phối nội dung có thể chọn một biến thể đã được mã hóa, một cổng có thể trả lời OPTIONS, một bộ nhớ đệm có thể sử dụng lại một phản hồi đã được thỏa thuận và một máy chủ ứng dụng có thể thiết lập cookie hoặc trường ủy quyền.

API Scraping Tối ưu Không Có Rác là thích hợp khi một đội cần quản lý việc truy xuất nội dung công cộng được phép, bao gồm các trang được render bằng JavaScript. Hợp đồng mua sắm vẫn nên xác định mục tiêu, các trường cho phép, đại diện mong đợi, dấu chấp nhận và điều kiện dừng.

Các Yêu cầu Thường Kích Hoạt Preflight

Yêu cầu Preflight có một vị trí trong kiến trúc khi nó thay đổi hành vi sản phẩm cụ thể, yêu cầu tương thích, hoặc quyết định chẩn đoán. Những trường hợp sử dụng này mô tả công việc trước và tính năng giao thức sau.

Các yêu cầu đã được preflight và CORS-Safelisted

Yêu cầu Preflight thuộc một lớp HTTP và không nên bị nhầm lẫn với các lớp liền kề. Một triển khai hợp lý xác định thành phần nào chọn giá trị, thành phần nào có thể thay đổi nó, và bằng chứng nào chứng minh rằng đại diện cuối cùng là chính xác.

Một sự so sánh chỉ hữu ích nếu nó bảo tồn ranh giới lớp. Hai cơ chế có thể tồn tại trong một yêu cầu, và việc thay thế một cái không tự động thay thế cái kia. Tài liệu hành vi đã chọn theo các đầu vào, đầu ra quan sát được, trạng thái thất bại và quyền sở hữu.

Tại sao Xử Lý Preflight Lại Gãy

• Chuyển hướng OPTIONS đến không có trình xử lý. Các cổng và khung có thể trả về một lỗi chung trước khi logic CORS của ứng dụng chạy.
• Cho phép phương pháp nhưng không cho phép trường. Phương pháp đã lập kế hoạch và mọi trường không nằm trong danh sách đã được yêu cầu phải được bao phủ.
• Yêu cầu thông tin thông thường trên OPTIONS. Hành vi preflight của Fetch không bao gồm thông tin xác thực yêu cầu bình thường.
• Quên phản hồi thực tế. Cả kiểm tra quyền và phản hồi sau đó đều cần chính sách nguồn áp dụng.
• Ghi lại chỉ nhật ký ứng dụng máy chủ. Một CDN, proxy hoặc máy chủ web có thể trả lời OPTIONS trước khi ứng dụng nhìn thấy nó.
• Vô hiệu hóa một trường yêu cầu cần thiết. Loại bỏ các trường bảo mật hoặc nội dung để tránh thực hiện trước có thể làm hỏng hợp đồng API.

Hầu hết các lỗi trở nên dễ chẩn đoán hơn sau khi loại bỏ những giả định về những gì một thư viện hoặc trình duyệt tự động thực hiện. Ghi lại một vết tích tối thiểu, bôi đen các bí mật và thay đổi một biến kiểm soát được mỗi lần. Mục tiêu là một giải thích ổn định của đại diện trả về, không phải là một tập hợp các điều chỉnh tiêu đề không liên quan.

Danh sách kiểm tra lỗi trước khi bay

Chuỗi này hoạt động như một đánh giá thiết kế trước khi ra mắt và như một chẩn đoán sản xuất sau khi thay đổi hành vi. Nó giữ chứng cứ giao thức liên kết với kết quả ứng dụng.

1. Xác định nguồn trang, nguồn mục tiêu, phương pháp hoạch định, loại nội dung và các trường do tác giả kiểm soát.
2. Mở trao đổi OPTIONS và đọc trạng thái cùng các trường phản hồi mà không giả định ứng dụng đã xử lý nó.
3. Khớp Access-Control-Allow-Origin với Origin yêu cầu theo các quy tắc thông tin xác thực.
4. Xác nhận rằng Access-Control-Allow-Methods bao gồm phương pháp đã hoạch định.
5. Xác nhận rằng Access-Control-Allow-Headers bao gồm mọi tên trường không nằm trong danh sách bảo mật được yêu cầu.
6. Kiểm tra chuyển hướng, proxy và bộ xử lý lỗi cho các phản hồi bỏ qua các trường CORS.
7. Sau khi OPTIONS qua, kiểm tra yêu cầu và phản hồi thực tế như một trao đổi riêng biệt.

Kết thúc đánh giá bằng cách lưu trữ một mẫu nhỏ đã được chấp nhận và một mẫu bị từ chối với cùng các quy tắc bôi đen. Những thay đổi trong tương lai có thể được so sánh với danh tính trang đã biết, các trường mong đợi và nội dung đã giải mã chứ không phải chỉ là bộ nhớ hoặc ảnh chụp màn hình.

Bảo mật và Giám sát cho Yêu cầu Trước khi bay

Yêu cầu trước khi bay tham gia vào một đường dẫn yêu cầu có thể vượt qua trình duyệt, cổng, bộ nhớ đệm và máy chủ nguồn. Mỗi lần nhảy nên chỉ chấp nhận các giá trị mà nó hiểu, bảo tồn các trường cần tồn tại và tránh sao chép thông tin xác thực hoặc dữ liệu cá nhân vào nhật ký. Cú pháp giao thức không phải là ủy quyền.

Các hồ sơ hoạt động nên ghi lại URL được yêu cầu, URL cuối cùng, trạng thái, loại biểu diễn, tên các trường liên quan và một dấu hiệu nội dung giới hạn. Toàn bộ thân thể và các giá trị thông tin xác thực hiếm khi cần thiết cho chẩn đoán thường lệ và có thể tạo ra rủi ro lưu giữ không cần thiết.

Hành vi trình duyệt và hành vi HTTP trực tiếp là những bề mặt kiểm tra khác nhau. CORS, lưu trữ cookie, giải nén tự động và xử lý chuyển hướng có thể được thực hiện bởi trình duyệt hoặc thư viện trước khi mã ứng dụng nhìn thấy một kết quả. Ghi lại khách hàng và các mặc định của nó khi so sánh các bản ghi lại.

Tiêu chuẩn định nghĩa yêu cầu trước khi bay

thuật toán trước khi bay của tiêu chuẩn Fetch định nghĩa kiểm tra chính sách của trình duyệt. Nguồn chính này cố định từ vựng và ranh giới được sử dụng trong bài viết này, trong khi hành vi triển khai vẫn cần được quan sát trong khách hàng và triển khai đã chọn.

từ điển yêu cầu trước khi bay của MDN hiển thị các trường yêu cầu OPTIONS. Nguồn chính này cố định từ vựng và ranh giới được sử dụng trong bài viết này, trong khi hành vi triển khai vẫn cần được quan sát trong khách hàng và triển khai đã chọn.

hướng dẫn CORS của MDN giải thích trước khi bay và các ràng buộc thông tin xác thực. Nguồn chính này cố định từ vựng và ranh giới được sử dụng trong bài viết này, trong khi hành vi triển khai vẫn cần được quan sát trong khách hàng và triển khai đã chọn.

các ngữ nghĩa HTTP OPTIONS định nghĩa phương thức HTTP cơ bản. Nguồn chính này cố định từ vựng và ranh giới được sử dụng trong bài viết này, trong khi hành vi triển khai vẫn cần được quan sát trong khách hàng và triển khai đã chọn.

Quy tắc gỡ lỗi trước khi bay

Xem xét yêu cầu trước khi bay và yêu cầu thực tế như hai trao đổi HTTP riêng biệt và xác thực hành vi nguồn, phương pháp, trường, thông tin xác thực, cổng và phản hồi cuối cùng ở lớp đã sản xuất từng phản hồi.

Đưa quy tắc đó vào một bài kiểm tra chấp nhận. Nêu rõ người tham gia nào gửi tín hiệu, người tham gia nào diễn giải nó, các trung gian nào có thể thay đổi đường dẫn và dấu hiệu nội dung nào chứng minh thành công. Điều này khiến Yêu cầu trước khi bay trở thành một phần của hệ thống có thể quan sát được thay vì chỉ là một nhãn gắn sau một lỗi.

Tài liệu tham khảo

• Tài liệu API thu thập dữ liệu toàn cầu không rác
• Tổng quan sản phẩm API thu thập dữ liệu toàn cầu không rác
• Hướng dẫn Scrapeless về tiêu đề, cookie, phiên và xác thực đại diện
• Scrapeless trên GitHub