Có sự khác biệt đáng kể nào trong cách các trình duyệt thực hiện chính sách cùng nguồn gốc không?

Question

Tôi có một biểu mẫu trên trang chủ của mình được thiết lập để gửi qua XHR POST tới URL https://mydomain.com/send_sms.

Khi tôi truy cập phiên bản không phải SSL của trang chủ trong Internet Explorer (http://mydomain.com) & hãy gửi biểu mẫu, không có gì xảy ra. Trong bảng điều khiển Webkit, tôi nhận được một lỗi hữu ích nêu rõ Origin http://mydomain.com is not allowed by Access-Control-Allow-Origin.

Tuy nhiên, yêu cầu gửi rõ ràng & trả về 200 OK, mặc dù nội dung phản hồi trống. Hơn nữa, hành động phía máy chủ (gửi một tin nhắn SMS) thực tế được kích hoạt bởi yêu cầu Firefox nhưng không phải là các trình duyệt khác.

Tôi luôn nghĩ rằng chính sách có cùng nguồn gốc bị từ chối ngay cả khi gửi yêu cầu, nhưng có lẽ đó là trình duyệt nhận dữ liệu từ phản hồi không được phép?

Bất kỳ ai biết đây có phải là sự khác biệt có mục đích trong việc triển khai (hoặc thậm chí có thể là sự giám sát) của Mozilla không?

Answer 1

Trước hết, http://example.com và https://example.com là các nguồn gốc khác nhau. Đối với XHR Level 1 điều này có nghĩa là các yêu cầu có nguồn gốc chéo không được phép.

Nhưng đối với dòng điện XHR (Level 2), mà hỗ trợ các yêu cầu cross-nguồn gốc khi CORS được hỗ trợ (bằng cả máy chủ và máy khách!), Một yêu cầu cross-nguồn gốc có thể là

• một simple cross-orgin request, nếu

  • phương thức yêu cầu là GET, HEAD, hoặc POST, và
  • không ai trong số các yêu cầu heade lĩnh vực r là ai khác ngoài Accept, Accept-Language, Content-Language, hoặc Content-Type, và
  • cờ preflight không được thiết lập

  hoặc

• một cross-origin request that requires a preflight, nếu không.

Đối với các yêu cầu có nguồn gốc đơn giản, trình duyệt được phép gửi yêu cầu. Nhưng khi nhận được phản hồi, nó cần phải check whether the server allows to share the resource. Đây là nơi mà trường tiêu đề Access-Control-Allow-Origin và các trường tiêu đề phản hồi Access-Control-* khác được chọn. Và chỉ khi kiểm tra này được thông qua, trình duyệt cho phép tập lệnh đọc phản hồi.

Đối với các yêu cầu gốc khác, cần phải có đèn nền để thương lượng với máy chủ thông tin nào được phép gửi trong yêu cầu thực tế. Yêu cầu preflight này về cơ bản là yêu cầu OPTIONS cho máy chủ biết yêu cầu thực tế sẽ chứa (trường yêu cầu và trường tiêu đề). Sau đó, máy chủ có thể quyết định xem nó có cho phép yêu cầu đó hay không.

Trong trường hợp của bạn, hành vi được quan sát có thể có nhiều lý do. Tôi đoán đoạn mã send_sms của bạn chỉ không support the server side part for CORS.

Answer 2

Việc gửi dữ liệu phải bị cấm nhiều như nhận được, ví dụ: điều gì xảy ra nếu có một số JS độc hại trên trang này và nó đã gửi mỗi lần gõ phím đến một số máy chủ ngẫu nhiên? Trong trường hợp này, việc gửi không chính xác hơn việc nhận (như một sang một bên, điều này thực sự có thể đạt được bằng cách yêu cầu các tài nguyên như hình ảnh hoặc tập lệnh, với chuỗi truy vấn, vì chúng không tuân theo chính sách gốc).

Tôi đã gặp phải sự khác biệt nhỏ trong quá khứ nhưng điều đó thường xảy ra với IE cũ.

Với tôi, sự khác biệt của firefox là lỗi (cung cấp bản cài đặt vani có đặc điểm này). Một giao thức khác (HTTP vs HTTPS) tương đương với một nguồn gốc khác nhau, ngay cả các miền phụ trên cùng một giao thức được coi là có nguồn gốc khác nhau, vì vậy FF13 chắc chắn không nên thực hiện yêu cầu AJAX.

Bạn không có thiết lập CORS (Cross-Origin Resource Sharing) và FF13 là trình duyệt duy nhất bạn đã thử nghiệm để hỗ trợ nó?