Preflight Request là gì? Giải thích các kiểm tra CORS

Scrapeless Agent Browser chạy các workflow dựa trên trình duyệt, trong đó các trang đích vẫn chịu các quy tắc yêu cầu cross-origin của trình duyệt.

Preflight đặt câu hỏi về một yêu cầu trình duyệt được đề xuất

Một preflight CORS là một yêu cầu HTTP OPTIONS mà trình duyệt gửi để kiểm tra xem máy chủ có cho phép một yêu cầu cross-origin cụ thể hay không. Nó mô tả origin gọi, phương thức dự định và các tên trường yêu cầu liên quan. Nếu phản hồi của máy chủ thỏa mãn các kiểm tra của trình duyệt, trình duyệt có thể tiếp tục với yêu cầu ứng dụng. Preflight là một cuộc thương lượng quyền trong mô hình truy cập của trình duyệt, không phải chính bản thân thao tác của ứng dụng.

Tiêu chuẩn Fetch Standard CORS model xác định hành vi này. Một origin được xác định bởi scheme, host và port, nên hai URL có thể thuộc các origin khác nhau ngay cả khi tên miền trông rất gần nhau. Một frontend được phục vụ từ một origin và một API được phục vụ từ origin khác có thể cần cấu hình CORS để JavaScript trên trình duyệt có thể truy cập phản hồi của API.

CORS là viết tắt của Cross-Origin Resource Sharing. Nó cho phép một máy chủ tự chọn tham gia vào một số tương tác cross-origin trong trình duyệt trong khuôn khổ mô hình bảo mật same-origin. Chính sách được thực thi bởi trình duyệt, trong khi máy chủ khai báo những gì nó cho phép thông qua các trường phản hồi. Một ứng dụng không thể giải quyết một yêu cầu cross-origin bị từ chối bằng cách thêm các trường quyền phản hồi vào chính yêu cầu gửi đi của nó.

Không phải mọi yêu cầu cross-origin đều có preflight

Một số yêu cầu cross-origin nằm trong tập phương thức và quy tắc trường được safelisted của CORS và không cần preflight. Các điều kiện chính xác bao gồm phương thức, giá trị trường yêu cầu và hành vi Fetch liên quan. Một yêu cầu GET với một trường không nằm trong safelist có thể cần preflight, trong khi một yêu cầu POST đủ ràng buộc có thể tránh được preflight. Vì vậy chỉ riêng tên phương thức là một quy tắc quyết định không đầy đủ.

Các tác nhân kích hoạt phổ biến bao gồm các phương thức ngoài tập safelisted, một trường Authorization, và kiểu nội dung JSON không nằm trong các media type được safelisted. Những ví dụ đó giải thích nhiều bản ghi vết mạng của trình duyệt, nhưng bài kiểm tra đầy đủ thuộc về các quy tắc Fetch. Tránh mô tả mọi GET là đơn giản hoặc mọi POST là có preflight. Hãy kiểm tra cấu hình yêu cầu thực tế.

Bài giải thích preflight request của trình duyệt phân biệt yêu cầu OPTIONS sơ bộ với yêu cầu thực. Máy chủ có thể nhận được các yêu cầu không cần preflight trong khi trình duyệt vẫn từ chối để JavaScript truy cập phản hồi của chúng. Do đó không nên mô tả CORS như một rào cản phổ quát ngăn mọi yêu cầu cross-origin đến được máy chủ.

Trình duyệt mô tả phương thức và các trường dự định sử dụng

Preflight bao gồm Origin để xác định origin gọi. Access-Control-Request-Method nêu tên phương thức mà trình duyệt dự định dùng cho yêu cầu thực. Access-Control-Request-Headers liệt kê các tên trường yêu cầu liên quan cần được cấp quyền. Đây là các mô tả về một thao tác được đề xuất; chúng không có nghĩa là chính yêu cầu OPTIONS thực hiện thao tác đó hoặc mang toàn bộ payload của ứng dụng.

Máy chủ phản hồi bằng các trường mô tả các origin, phương thức và trường yêu cầu được phép khi áp dụng. Trình duyệt đánh giá các khai báo đó so với yêu cầu được đề xuất. Một bộ xử lý OPTIONS chung chỉ trả về thành công là không đủ khi nó bỏ sót quyền cần thiết hoặc cấp một phương thức khác. Hãy giữ phép so sánh chính xác để việc chẩn đoán xác định được phần chính sách nào đã thất bại.

Một yêu cầu ứng dụng vẫn là một trao đổi riêng biệt. Khi nó đến, API sẽ xác thực thông tin xác thực, tham số và quyền hạn của nó. Phản hồi của nó cũng cần các trường CORS phù hợp để trình duyệt có thể truy cập. Vượt qua kiểm tra sơ bộ không khiến một thao tác ứng dụng về sau không được ủy quyền hoặc bị lỗi định dạng trở nên thành công, và cũng không miễn cho phản hồi thực tế khỏi việc xử lý theo chính sách nguồn gốc.

Thông tin xác thực khiến cấu hình nguồn gốc cụ thể hơn

Các yêu cầu trình duyệt có thông tin xác thực cần chính sách phản hồi CORS khớp với chế độ thông tin xác thực và nguồn gốc đang yêu cầu. Một nguồn gốc được cho phép dạng wildcard không thể được dùng như một thay thế chung cho nguồn gốc tường minh khi để lộ một phản hồi có thông tin xác thực. Máy chủ cũng cần quyền thông tin xác thực phù hợp. Hãy cấu hình các trường này từ một chính sách nguồn gốc được kiểm soát thay vì phản chiếu đầu vào tùy ý mà không kiểm tra.

Cookie đưa vào các quy tắc bổ sung ngoài CORS. Một yêu cầu có thể đáp ứng chính sách CORS của nó trong khi việc chuyển cookie bị ràng buộc bởi các thuộc tính cookie hoặc hành vi bảo mật của trình duyệt. Ngược lại, sự hiện diện của cookie không thiết lập rằng máy chủ đã chấp nhận phiên. Hãy giữ việc phân phối cookie, phạm vi phơi bày CORS và ủy quyền của ứng dụng như những câu hỏi chẩn đoán riêng biệt.

The Hướng dẫn về thông tin xác thực CORS và trường phản hồi bao quát những tương tác này. Một preflight theo mô hình chuẩn thường loại trừ thông tin xác thực, ngay cả khi yêu cầu ứng dụng được đề xuất có thông tin xác thực. Middleware yêu cầu phiên đã đăng nhập cho mọi yêu cầu OPTIONS vì vậy có thể chặn việc thương lượng trước khi yêu cầu ứng dụng đã được ủy quyền được đánh giá.

Preflight thất bại và Lệnh gọi API thất bại là khác nhau

Một preflight thất bại có thể khiến trình duyệt không gửi yêu cầu ứng dụng được đề xuất. Trong trường hợp đó, route API có thể không có thao tác ứng dụng tương ứng trong log của nó, trong khi gateway ghi lại OPTIONS. Hãy bắt đầu chẩn đoán bằng cách xác định trao đổi nào đã xảy ra. Một lỗi CORS chung chung trong console tự nó không xác định được liệu định tuyến, chính sách trường, thông tin xác thực hay phản hồi thực tế gây ra sự cố.

Nếu yêu cầu ứng dụng đã đến máy chủ, hãy kiểm tra trạng thái riêng và các trường phản hồi CORS của nó. Một dịch vụ có thể trả về nội dung lỗi hữu ích mà JavaScript trên trình duyệt không thể đọc vì phản hồi lỗi đã bỏ sót quyền nguồn gốc. Áp dụng chính sách CORS dự định một cách nhất quán cho các phản hồi thành công và lỗi được hỗ trợ trong khi vẫn giữ nguyên ủy quyền API bình thường. Đừng biến mọi thất bại thành một thay đổi danh sách cho phép nguồn gốc.

Một yêu cầu OPTIONS không phải lúc nào cũng là preflight CORS. HTTP định nghĩa OPTIONS một cách tổng quát hơn như một yêu cầu về các tùy chọn giao tiếp cho tài nguyên đích. Các ngữ nghĩa HTTP OPTIONS và sự hiện diện của các trường yêu cầu CORS giúp phân biệt preflight của trình duyệt với một yêu cầu OPTIONS được gửi thủ công hoặc một lần kiểm tra hạ tầng khác. Hãy chẩn đoán chính yêu cầu đang hiện hữu thay vì chỉ dựa vào tên phương thức của nó.

Bộ nhớ đệm Preflight có vòng đời riêng

Trình duyệt có thể lưu vào bộ nhớ đệm một quyền preflight thành công theo các quy tắc áp dụng, bao gồm Access-Control-Max-Age và các giới hạn hiện thực. Bộ nhớ đệm đó tách biệt với nội dung phản hồi ứng dụng được lưu trong bộ nhớ đệm thông thường. Nó có thể giải thích vì sao một yêu cầu về sau xuất hiện mà không có trao đổi OPTIONS mới. Việc thiếu preflight trong một bản ghi truy vết không chứng minh rằng yêu cầu sẽ không bao giờ cần một preflight.

Phạm vi bộ nhớ đệm cũng phụ thuộc vào ngữ cảnh yêu cầu, nguồn gốc, đích, phương thức và quyền trường. Một lần kiểm tra thành công cho một route hoặc tập trường không phải là sự chấp thuận bao trùm cho mọi thao tác tại host. Khi gỡ lỗi, hãy ghi lại phương thức được đề xuất và các trường yêu cầu cùng với URL đích. So sánh các truy vết mà không có những chi tiết đó có thể khiến các khác biệt chính sách bình thường trông có vẻ không nhất quán.

Một máy chủ trả về quyền nguồn gốc khác nhau cho các bên gọi khác nhau nên tính đến hành vi bộ nhớ đệm trung gian. Các quy tắc lựa chọn bộ nhớ đệm HTTP giải thích cách biến thể phản hồi phải được biểu diễn để ngăn việc tái sử dụng không phù hợp. Khi một phản hồi ứng dụng thay đổi theo Origin, hãy cấu hình biến thể bộ nhớ đệm liên quan thay vì cho phép tuyên bố nguồn gốc của một bên gọi được tái sử dụng một cách bừa bãi cho bên khác.

Gỡ lỗi trao đổi từ nguồn gốc đến ứng dụng

Bắt đầu với đầy đủ nguồn gốc của trang gọi và đích API cuối cùng. Kiểm tra xem liệu chuyển hướng hoặc gateway có định tuyến OPTIONS khác với phương thức ứng dụng hay không. So sánh phương thức và các trường được đề xuất với chính sách rõ ràng của máy chủ. Sau đó kiểm tra xem yêu cầu thực tế đã đến hay chưa và liệu phản hồi của nó có bao gồm các trường CORS như mong đợi hay không. Trình tự này xác định vị trí lỗi mà không làm suy yếu chính sách một cách bừa bãi.

Một client dòng lệnh có thể giúp kiểm tra phản hồi HTTP, nhưng bản thân nó không tái tạo việc thực thi CORS của trình duyệt. Một yêu cầu thành công từ một tiến trình backend chỉ chứng minh rằng tiến trình này đã nhận được phản hồi trong ngữ cảnh mạng và thông tin xác thực của riêng nó. Trình duyệt vẫn đánh giá các quy tắc nguồn gốc. Việc đổi client sang chế độ ẩn phản hồi không tạo ra quyền đọc nội dung phản hồi được bảo vệ.

Giữ cho dữ liệu chẩn đoán được làm sạch. Giá trị ủy quyền và cookie không nên được dán vào các bản ghi truy vết chia sẻ. Thông thường tên trường, nguồn gốc, route, phương thức, trạng thái và giá trị trường quyền là đủ để giải thích một sai lệch CORS. Nếu ứng dụng động chạm đến hồ sơ cá nhân, chỉ thu thập lượng nội dung tối thiểu cần thiết cho cuộc điều tra đã được ủy quyền và giữ việc thu thập đó trong phạm vi truy cập thích hợp.

Tự động hóa trình duyệt vẫn tuân theo mô hình nguồn gốc

Giữ kết nối điều khiển trình duyệt tách biệt với JavaScript thực thi bên trong trang đích. Một client tự động hóa truy cập một trình duyệt đám mây và một script trên trang truy cập một API cross-origin là các tương tác mạng khác nhau. Thành công trên kênh điều khiển không thể chứng minh rằng lời gọi API của trang đã vượt qua CORS. Hãy quan sát yêu cầu đích và phản hồi tương ứng của nó khi giải thích những gì trang có thể truy cập.

The Quy trình yêu cầu Fetch là tài liệu liên quan dành cho các HTTP client, và Scrapeless pricing bao quát việc sử dụng dịch vụ trình duyệt. Đối với một bài kiểm tra đã được ủy quyền, hãy xác định rõ origin mong đợi, thao tác, và kết quả hiển thị trên trang. Một quan sát trình duyệt đạt yêu cầu nên xác nhận cả việc trao đổi chính sách và hành vi ứng dụng kết quả, thay vì dừng lại ở trạng thái OPTIONS.

Kết luận

Một preflight đánh giá một thao tác cross-origin cụ thể được đề xuất trước khi một số yêu cầu trình duyệt tiếp tục. Hãy kiểm tra origin của bên gọi, method, tên trường, chế độ thông tin xác thực, và cả hai phản hồi. Giữ việc kiểm tra quyền của trình duyệt tách biệt với ủy quyền API, và chẩn đoán chính sách tại thành phần sở hữu lần trao đổi bị lỗi.