Rõ ràng, tôi đã hoàn toàn hiểu sai về ngữ nghĩa của nó. Tôi nghĩ về một cái gì đó như thế này:

1. Một khách hàng tải xuống mã javascript MyCode.js từ http://siteA- nguồn gốc .
2. Tiêu đề phản hồi của MyCode.js chứa Access-Control-Allow-Origin :http://siteB , mà tôi nghĩ có nghĩa là MyCode.js được phép tạo tham chiếu nguồn gốc chéo đến trang web B.
3. Máy khách kích hoạt một số chức năng của MyCode.js, lần lượt thực hiện các yêu cầu http://siteB, sẽ ổn, mặc dù là các yêu cầu có nguồn gốc chéo.

Vâng, tôi sai. Nó hoàn toàn không hoạt động như thế này. Vì vậy, tôi đã đọc Chia sẻ tài nguyên nguồn gốc chéo và cố gắng đọc Chia sẻ tài nguyên nguồn gốc chéo trong đề xuất w3c

Một điều chắc chắn - tôi vẫn không hiểu tôi nên sử dụng tiêu đề này như thế nào.

Tôi có toàn quyền kiểm soát cả trang A và trang B. Làm cách nào để kích hoạt mã javascript được tải xuống từ trang A để truy cập tài nguyên trên trang B bằng tiêu đề này?

PS

Tôi không muốn sử dụng JSONP.

Access-Control-Allow-Originlà một tiêu đề CORS (Chia sẻ tài nguyên nguồn gốc) .

Khi Trang A cố gắng tìm nạp nội dung từ Trang B, Trang B có thể gửi Access-Control-Allow-Origintiêu đề phản hồi để cho trình duyệt biết rằng nội dung của trang này có thể truy cập được theo một số nguồn gốc nhất định. ( Nguồn gốc là một miền, cộng với lược đồ và số cổng .) Theo mặc định, các trang của Trang B không thể truy cập được đối với bất kỳ nguồn gốc nào khác ; sử dụng Access-Control-Allow-Origintiêu đề sẽ mở ra một cánh cửa để truy cập nguồn gốc chéo bằng nguồn gốc yêu cầu cụ thể.

Đối với mỗi tài nguyên / trang mà Trang B muốn truy cập vào Trang A, Trang B nên phục vụ các trang của nó với tiêu đề phản hồi:

Access-Control-Allow-Origin: http://siteA.com

Các trình duyệt hiện đại sẽ không chặn hoàn toàn các yêu cầu tên miền chéo. Nếu Trang A yêu cầu một trang từ Trang B, trình duyệt sẽ thực sự tìm nạp trang được yêu cầu ở cấp mạng và kiểm tra xem các tiêu đề phản hồi có liệt kê Trang A là miền yêu cầu được phép hay không. Nếu trang web của B đã không chỉ ra rằng trang web A được phép truy cập vào trang này, trình duyệt sẽ kích hoạt XMLHttpRequest's errorsự kiện và từ chối các dữ liệu đáp ứng với mã JavaScript yêu cầu.

Yêu cầu không đơn giản

Điều gì xảy ra ở cấp độ mạng có thể phức tạp hơn một chút so với giải thích ở trên. Nếu yêu cầu là một yêu cầu "không đơn giản" , trước tiên trình duyệt sẽ gửi một yêu cầu TÙY CHỌN "không có dữ liệu" để xác minh rằng máy chủ sẽ chấp nhận yêu cầu. Một yêu cầu không đơn giản khi một trong hai (hoặc cả hai):

• sử dụng một động từ HTTP khác với GET hoặc POST (ví dụ PUT, DELETE)
• sử dụng các tiêu đề yêu cầu không đơn giản; các tiêu đề yêu cầu đơn giản là:
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type(điều này chỉ đơn giản khi giá trị của nó là application/x-www-form-urlencoded, multipart/form-datahoặc text/plain)

Nếu máy chủ phản hồi ánh sáng trước TÙY CHỌN với các tiêu đề phản hồi thích hợp ( Access-Control-Allow-Headersđối với các tiêu đề không đơn giản, Access-Control-Allow-Methodscho các động từ không đơn giản) phù hợp với các động từ không đơn giản và / hoặc các tiêu đề không đơn giản, thì trình duyệt sẽ gửi yêu cầu thực tế.

Giả sử Trang web A muốn gửi yêu cầu PUT /somePage, với Content-Typegiá trị không đơn giản application/json, trước tiên, trình duyệt sẽ gửi yêu cầu preflight:

OPTIONS /somePage HTTP/1.1
Origin: http://siteA.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type

Lưu ý rằng Access-Control-Request-Methodvà Access-Control-Request-Headersđược trình duyệt thêm tự động; bạn không cần thêm chúng. Đèn chiếu TÙY CHỌN này nhận được các tiêu đề phản hồi thành công:

Access-Control-Allow-Origin: http://siteA.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type

Khi gửi yêu cầu thực tế (sau khi thực hiện preflight), hành vi giống hệt như cách xử lý một yêu cầu đơn giản. Nói cách khác, một yêu cầu không đơn giản có preflight thành công được xử lý giống như một yêu cầu đơn giản (nghĩa là, máy chủ vẫn phải gửi Access-Control-Allow-Originlại cho phản hồi thực tế).

Các trình duyệt gửi yêu cầu thực tế:

PUT /somePage HTTP/1.1
Origin: http://siteA.com
Content-Type: application/json

{ "myRequestContent": "JSON is so great" }

Và máy chủ gửi lại Access-Control-Allow-Origin, giống như yêu cầu đơn giản:

Access-Control-Allow-Origin: http://siteA.com

Xem Hiểu XMLHttpRequest qua CORS để biết thêm một chút thông tin về các yêu cầu không đơn giản.

Theo chia sẻ tài nguyên nguồn gốc chéo - CORS(Yêu cầu AJAX tên miền chéo AKA) là vấn đề mà hầu hết các nhà phát triển web có thể gặp phải, theo Same-Origin-Policy, các trình duyệt hạn chế JavaScript máy khách trong hộp cát bảo mật, thông thường, JS không thể giao tiếp trực tiếp với máy chủ từ xa từ một miền khác nhau. Trước đây, các nhà phát triển đã tạo ra nhiều cách khó khăn để đạt được yêu cầu tài nguyên Tên miền chéo, phổ biến nhất là sử dụng các cách là:

1. Sử dụng Flash / Silverlight hoặc phía máy chủ làm "proxy" để liên lạc với điều khiển từ xa.
2. JSON có đệm ( JSONP ).
3. Nhúng máy chủ từ xa vào iframe và liên lạc qua đoạn hoặc window.name, tham khảo tại đây .

Những cách khó khăn đó có ít nhiều vấn đề, ví dụ JSONP có thể dẫn đến lỗ hổng bảo mật nếu các nhà phát triển chỉ đơn giản là "đánh bại" nó và # 3 ở trên, mặc dù nó hoạt động, cả hai miền nên xây dựng hợp đồng chặt chẽ với nhau, nó không linh hoạt hay thanh lịch IMHO :)

W3C đã giới thiệu Chia sẻ tài nguyên nguồn gốc chéo (CORS) như một giải pháp tiêu chuẩn để cung cấp một cách an toàn, linh hoạt và là một cách tiêu chuẩn được đề xuất để giải quyết vấn đề này.

Cơ chế

Từ cấp độ cao, chúng ta có thể coi CORS là một hợp đồng giữa cuộc gọi AJAX của khách hàng từ miền A và một trang được lưu trữ trên miền B, một yêu cầu / phản hồi Cross-Origin điển hình sẽ là:

Tiêu đề yêu cầu AJA của DomainA

Host DomainB.com
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/json
Accept-Language en-us;
Accept-Encoding gzip, deflate
Keep-Alive 115
Origin http://DomainA.com 

Tiêu đề phản hồi của DomainB

Cache-Control private
Content-Type application/json; charset=utf-8
Access-Control-Allow-Origin DomainA.com
Content-Length 87
Proxy-Connection Keep-Alive
Connection Keep-Alive

Các phần màu xanh mà tôi đã đánh dấu ở trên là các sự kiện hạt nhân, "Tiêu đề yêu cầu gốc" cho biết yêu cầu xuất xứ chéo hoặc yêu cầu preflight bắt nguồn từ ", tiêu đề phản hồi" Access-Control-Allow-Origin "cho biết trang này cho phép yêu cầu từ xa DomainA (nếu giá trị là * cho phép yêu cầu từ xa từ bất kỳ miền nào).

Như tôi đã đề cập ở trên, W3 đã đề xuất trình duyệt thực hiện " yêu cầu preflight " trước khi gửi yêu cầu HTTP có nguồn gốc thực sự, tóm lại, đây là một OPTIONSyêu cầu HTTP :

OPTIONS DomainB.com/foo.aspx HTTP/1.1

Nếu foo.aspx hỗ trợ động từ HTTP TÙY CHỌN, nó có thể trả về phản hồi như bên dưới:

HTTP/1.1 200 OK
Date: Wed, 01 Mar 2011 15:38:19 GMT
Access-Control-Allow-Origin: http://DomainA.com
Access-Control-Allow-Methods: POST, GET, OPTIONS, HEAD
Access-Control-Allow-Headers: X-Requested-With
Access-Control-Max-Age: 1728000
Connection: Keep-Alive
Content-Type: application/json

Chỉ khi phản hồi chứa "Kiểm soát truy cập-Cho phép-Xuất xứ" VÀ giá trị của nó là "*" hoặc chứa tên miền đã gửi yêu cầu CORS, bằng cách đáp ứng trình duyệt điều kiện bắt buộc này sẽ gửi yêu cầu Tên miền chéo thực tế và lưu trữ kết quả vào bộ đệm trong " Preflight-result-Cache ".

Tôi đã viết blog về CORS ba năm trước: Yêu cầu HTTP có nguồn gốc chéo AJAX

Câu hỏi hơi quá cũ để trả lời, nhưng tôi đang đăng bài này cho bất kỳ tài liệu tham khảo nào trong tương lai cho câu hỏi này.

Theo này Mozilla Developer bài viết Mạng,

Tài nguyên tạo một yêu cầu HTTP có nguồn gốc chéo khi nó yêu cầu tài nguyên từ một tên miền hoặc cổng khác với tài nguyên mà chính tài nguyên đầu tiên phục vụ.

Một trang HTML được phục vụ từ http://domain-a.comlàm cho một <img>yêu cầu src cho http://domain-b.com/image.jpg.
Nhiều trang trên web ngày nay tải các tài nguyên như bảng định kiểu CSS , hình ảnh và tập lệnh từ các tên miền riêng biệt (do đó nó sẽ rất tuyệt).

Chính sách cùng nguồn gốc

Vì lý do bảo mật, các trình duyệt hạn chế các yêu cầu HTTP có nguồn gốc chéo được bắt đầu từ bên trong các tập lệnh .
Ví dụ, XMLHttpRequestvà làm Fetchtheo chính sách cùng nguồn gốc .
Vì vậy, một ứng dụng web sử dụng XMLHttpRequesthoặc Fetchchỉ có thể thực hiện các yêu cầu HTTP đến tên miền của chính nó .

Chia sẻ tài nguyên chéo (CORS)

Để cải thiện các ứng dụng web, các nhà phát triển đã yêu cầu các nhà cung cấp trình duyệt cho phép các yêu cầu tên miền chéo.

Cơ chế chia sẻ tài nguyên nguồn gốc chéo (CORS) cung cấp cho các máy chủ web các điều khiển truy cập tên miền chéo , cho phép truyền dữ liệu giữa các miền an toàn.
Các trình duyệt hiện đại sử dụng CORS trong bộ chứa API - chẳng hạn như XMLHttpRequesthoặc Fetch- để giảm thiểu rủi ro của các yêu cầu HTTP có nguồn gốc chéo.

Cách CORS hoạt động ( Access-Control-Allow-Origintiêu đề)

Wikipedia :

Tiêu chuẩn CORS mô tả các tiêu đề HTTP mới cung cấp cho trình duyệt và máy chủ cách yêu cầu URL từ xa chỉ khi chúng có quyền.

Mặc dù máy chủ có thể thực hiện một số xác thực và ủy quyền, nhưng nói chung, trách nhiệm của trình duyệt là hỗ trợ các tiêu đề này và tôn trọng các hạn chế mà chúng áp đặt.

Thí dụ

1. Trình duyệt gửi OPTIONSyêu cầu với một Origin HTTPtiêu đề.

   Giá trị của tiêu đề này là tên miền phục vụ trang mẹ. Khi một trang từ các http://www.example.comnỗ lực truy cập dữ liệu của người dùng vào service.example.com, tiêu đề yêu cầu sau sẽ được gửi đến service.example.com:

   Xuất xứ: http://www.example.com

2. Máy chủ tại service.example.comcó thể phản hồi với:

   • Một Access-Control-Allow-Origintiêu đề (ACAO) trong phản hồi của nó cho biết trang web gốc nào được phép.
     Ví dụ:

     Access-Control-Allow-Origin: http://www.example.com

   • Trang lỗi nếu máy chủ không cho phép yêu cầu xuất xứ chéo

   • Một Access-Control-Allow-Origin(ACAO) tiêu đề với một ký tự đại diện cho phép tất cả các lĩnh vực:

     Access-Control-Allow-Origin: *

Bất cứ khi nào tôi bắt đầu nghĩ về CORS, trực giác của tôi về trang web nào lưu trữ các tiêu đề là không chính xác, giống như bạn mô tả trong câu hỏi của bạn. Đối với tôi, nó giúp suy nghĩ về mục đích của chính sách xuất xứ tương tự.

Mục đích của chính sách nguồn gốc tương tự là để bảo vệ bạn khỏi JavaScript độc hại trên trang webA.com truy cập thông tin cá nhân bạn đã chọn để chỉ chia sẻ với siteB.com. Nếu không có chính sách nguồn gốc giống nhau, JavaScript được viết bởi các tác giả của siteA.com có ​​thể khiến trình duyệt của bạn thực hiện các yêu cầu tới siteB.com, sử dụng cookie xác thực của bạn cho siteB.com. Bằng cách này, siteA.com có ​​thể đánh cắp thông tin bí mật mà bạn chia sẻ với siteB.com.

Đôi khi bạn cần làm việc với tên miền chéo, đó là nơi CORS xuất hiện. CORS nới lỏng chính sách nguồn gốc tương tự cho domainB.com, sử dụng Access-Control-Allow-Origintiêu đề để liệt kê các tên miền khác (domainA.com) được tin cậy để chạy JavaScript có thể tương tác với domainA. com.

Để hiểu tên miền nào sẽ phục vụ các tiêu đề CORS, hãy xem xét điều này. Bạn truy cập độc hại.com, trong đó có một số JavaScript cố gắng thực hiện một yêu cầu tên miền chéo tới mybank.com. Nó phải tùy thuộc vào mybank.com, chứ không phải độc hại.com, để quyết định xem nó có đặt các tiêu đề CORS thư giãn chính sách nguồn gốc tương tự cho phép JavaScript từ tox.com tương tác với nó hay không. Nếu malicous.com có ​​thể đặt các tiêu đề CORS riêng cho phép truy cập JavaScript của riêng mình vào mybank.com, thì điều này sẽ hoàn toàn vô hiệu hóa chính sách xuất xứ tương tự.

Tôi nghĩ lý do cho trực giác xấu của tôi là quan điểm tôi có khi phát triển một trang web. Đó là trang web của tôi , với tất cả JavaScript của tôi , do đó, nó không gây hại gì và tôi phải chỉ định những trang web khác mà JavaScript của tôi có thể tương tác. Trong thực tế, tôi nên suy nghĩ những trang web nào JavaScript đang cố tương tác với trang web của tôi và tôi có nên sử dụng CORS để cho phép chúng không?

1. Một khách hàng tải xuống mã javascript MyCode.js từ http: // siteA - nguồn gốc.

Mã thực hiện tải xuống - thẻ script html của bạn hoặc xhr từ javascript hoặc bất cứ thứ gì - đến từ, giả sử, http: // siteZ . Và, khi trình duyệt yêu cầu MyCode.js, nó sẽ gửi tiêu đề Origin: "Origin: http: // siteZ ", bởi vì nó có thể thấy rằng bạn đang yêu cầu siteA và siteZ! = SiteA. (Bạn không thể dừng hoặc can thiệp vào việc này.)

2. Tiêu đề phản hồi của MyCode.js chứa Access-Control-Allow-Origin: http: // siteB , mà tôi nghĩ có nghĩa là MyCode.js được phép tạo tham chiếu nguồn gốc chéo đến trang web B.

Không. Điều đó có nghĩa là, chỉ siteB mới được phép thực hiện yêu cầu này. Vì vậy, yêu cầu của bạn đối với MyCode.js từ siteZ bị lỗi thay vào đó và trình duyệt thường không cung cấp cho bạn gì. Nhưng nếu bạn làm cho máy chủ của mình trả về ACAO: siteZ, bạn sẽ nhận được MyCode.js. Hoặc nếu nó gửi '*', nó sẽ hoạt động, điều đó sẽ cho phép mọi người tham gia. Hoặc nếu máy chủ luôn gửi chuỗi từ tiêu đề Origin: ... nhưng ... để bảo mật, nếu bạn sợ tin tặc , máy chủ của bạn chỉ nên cho phép nguồn gốc trong danh sách rút gọn, được phép thực hiện những yêu cầu đó.

Sau đó, MyCode.js đến từ trang webA. Khi nó đưa ra yêu cầu cho siteB, tất cả chúng đều có nguồn gốc chéo, trình duyệt sẽ gửi Origin: siteA và siteB phải lấy siteA, nhận ra nó trong danh sách ngắn những người yêu cầu được phép và gửi lại ACAO: siteA. Chỉ sau đó trình duyệt mới cho phép tập lệnh của bạn nhận được kết quả của những yêu cầu đó.

Sử dụng React và Axios , tham gia liên kết proxy đến URL và thêm tiêu đề như bên dưới

https://cors-anywhere.herokuapp.com/ + Your API URL

Chỉ cần thêm liên kết Proxy sẽ hoạt động, nhưng nó cũng có thể gây ra lỗi cho Không truy cập lại. Do đó tốt hơn để thêm tiêu đề như dưới đây.

axios.get(`https://cors-anywhere.herokuapp.com/[YOUR_API_URL]`,{headers: {'Access-Control-Allow-Origin': '*'}})
      .then(response => console.log(response:data);
  }

CẢNH BÁO: Không được sử dụng trong sản xuất

Đây chỉ là một sửa chữa nhanh chóng, nếu bạn đang đấu tranh với lý do tại sao bạn không thể nhận được phản hồi, bạn CÓ THỂ sử dụng điều này. Nhưng một lần nữa, nó không phải là câu trả lời tốt nhất cho sản xuất.

Có một số downvote và nó hoàn toàn có ý nghĩa, tôi nên đã thêm cảnh báo từ lâu.

Nếu bạn chỉ muốn kiểm tra một ứng dụng tên miền chéo trong đó trình duyệt chặn yêu cầu của bạn, thì bạn chỉ có thể mở trình duyệt của mình ở chế độ không an toàn và kiểm tra ứng dụng của bạn mà không thay đổi mã của bạn và không làm cho mã của bạn không an toàn. Từ MAC OS, bạn có thể thực hiện việc này từ dòng thiết bị đầu cuối:

open -a Google\ Chrome --args --disable-web-security --user-data-dir

Nếu bạn đang sử dụng PHP, hãy thử thêm đoạn mã sau vào đầu tệp php:

Nếu bạn đang sử dụng localhost, hãy thử điều này:

header("Access-Control-Allow-Origin: *");

Nếu bạn đang sử dụng các tên miền bên ngoài như máy chủ, hãy thử điều này:

header("Access-Control-Allow-Origin: http://www.website.com");

Tôi làm việc với express 4 và nút 7.4 và góc cạnh, tôi gặp vấn đề tương tự tôi giúp điều này:
a) phía máy chủ: trong tệp app.js tôi đưa ra các tiêu đề cho tất cả các phản hồi như:

app.use(function(req, res, next) {  
      res.header('Access-Control-Allow-Origin', req.headers.origin);
      res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
      next();
 });  

cái này phải có trước tất cả các bộ định tuyến .
Tôi đã thấy rất nhiều tiêu đề được thêm vào này:

res.header("Access-Control-Allow-Headers","*");
res.header('Access-Control-Allow-Credentials', true);
res.header('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE');

nhưng tôi không cần điều đó,
b) phía máy khách: trong send ajax bạn cần thêm: "withCredentials: true", như:

$http({
     method: 'POST',
     url: 'url, 
     withCredentials: true,
     data : {}
   }).then(function(response){
        // code  
   }, function (response) {
         // code 
   });

chúc may mắn.

Để chia sẻ nguồn gốc chéo, hãy đặt tiêu đề: 'Access-Control-Allow-Origin':'*';

Php: header('Access-Control-Allow-Origin':'*');

Nút: app.use('Access-Control-Allow-Origin':'*');

Điều này sẽ cho phép chia sẻ nội dung cho các tên miền khác nhau.

Trong Python tôi đã sử dụng Flask-CORSthư viện rất thành công. Nó làm cho việc đối phó với CORS siêu dễ dàng và không đau. Tôi đã thêm một số mã từ tài liệu của thư viện dưới đây.

Cài đặt:

$ pip install -U flask-cors

Ví dụ đơn giản cho phép CORS cho tất cả các tên miền trên tất cả các tuyến đường:

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

@app.route("/")
def helloWorld():
  return "Hello, cross-origin-world!"

Để biết ví dụ cụ thể hơn xem tài liệu. Tôi đã sử dụng ví dụ đơn giản ở trên để giải quyết vấn đề CORS trong một ứng dụng ion mà tôi đang xây dựng phải truy cập vào một máy chủ bình riêng.

Từ kinh nghiệm của riêng tôi, thật khó để tìm thấy một lời giải thích đơn giản tại sao CORS thậm chí là một mối quan tâm.

Khi bạn hiểu tại sao nó ở đó, các tiêu đề và thảo luận sẽ trở nên rõ ràng hơn rất nhiều. Tôi sẽ cho nó một shot trong một vài dòng.

Đó là tất cả về cookie. Cookies được lưu trữ trên một khách hàng theo tên miền của họ.

Một câu chuyện ví dụ: Trên máy tính của bạn, có một cookie cho yourbank.com. Có lẽ phiên của bạn là ở đó.

Điểm then chốt: Khi khách hàng đưa ra yêu cầu đến máy chủ, nó sẽ gửi cookie được lưu trữ dưới tên miền mà máy khách đang bật.

Bạn đã đăng nhập vào trình duyệt của mình yourbank.com. Bạn yêu cầu để xem tất cả các tài khoản của bạn. yourbank.comnhận được đống cookie và gửi lại phản hồi của nó (tài khoản của bạn).

Nếu một khách hàng khác thực hiện yêu cầu xuất xứ chéo tới máy chủ, những cookie đó sẽ được gửi cùng, giống như trước đây. Ruh roh.

Bạn duyệt đến malicious.com. Malicy thực hiện một loạt các yêu cầu cho các ngân hàng khác nhau, bao gồm cả yourbank.com.

Vì các cookie được xác thực như mong đợi, máy chủ sẽ cho phép phản hồi.

Những cookie này được tập hợp lại và gửi cùng - và bây giờ, malicious.comcó phản hồi từ yourbank.

Rất tiếc.

Vì vậy, bây giờ, một vài câu hỏi và câu trả lời trở nên rõ ràng:

• "Tại sao chúng ta không chặn trình duyệt làm điều đó?" Vâng. CORS.
• "Làm thế nào để chúng ta có được xung quanh nó?" Yêu cầu máy chủ thông báo rằng CORS vẫn ổn.

Chỉ cần dán mã sau vào tệp web.config của bạn.

Lưu ý rằng, bạn phải dán đoạn mã sau dưới <system.webServer>thẻ

    <httpProtocol>  
    <customHeaders>  
     <add name="Access-Control-Allow-Origin" value="*" />  
     <add name="Access-Control-Allow-Headers" value="Content-Type" />  
     <add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />  
    </customHeaders>  
  </httpProtocol>  

Tiêu đề phản hồi Access-Control-Allow-Origin cho biết liệu phản hồi có thể được chia sẻ với mã yêu cầu từ nguồn gốc đã cho hay không.

Header type Response       header
Forbidden header name      no

Một phản hồi yêu cầu trình duyệt cho phép mã từ bất kỳ nguồn gốc nào truy cập vào tài nguyên sẽ bao gồm các thông tin sau:

Access-Control-Allow-Origin: *

Để biết thêm thông tin, hãy truy cập vào đây ....

Nginx và Appache

Ngoài câu trả lời của apsillers, tôi muốn thêm biểu đồ wiki hiển thị khi yêu cầu có đơn giản hay không (và yêu cầu trước chuyến bay có được gửi hay không)

Đối với yêu cầu đơn giản (ví dụ: hình ảnh liên kết nóng ), bạn không cần thay đổi tệp cấu hình máy chủ của mình nhưng bạn có thể thêm các tiêu đề trong ứng dụng (được lưu trữ trên máy chủ, ví dụ như trong php) như Melvin Guerrero đề cập trong câu trả lời của mình - nhưng hãy nhớ : nếu bạn thêm đầy đủ tiêu đề cors trong máy chủ của bạn (config) và đồng thời bạn cho phép các cors đơn giản trên ứng dụng (ví dụ: php) điều này sẽ không hoạt động.

Và đây là cấu hình cho hai máy chủ phổ biến

• bật CORS trên Nginx ( nginx.conftệp)

  Hiển thị đoạn mã

  location ~ ^/index\.php(/|$) {
     ...
      add_header 'Access-Control-Allow-Origin' "$http_origin" always; # if you change "$http_origin" to "*" you shoud get same result - allow all domain to CORS (but better change it to your particular domain)
      add_header 'Access-Control-Allow-Credentials' 'true' always;
      if ($request_method = OPTIONS) {
          add_header 'Access-Control-Allow-Origin' "$http_origin"; # DO NOT remove THIS LINES (doubled with outside 'if' above)
          add_header 'Access-Control-Allow-Credentials' 'true';
          add_header 'Access-Control-Max-Age' 1728000; # cache preflight value for 20 days
          add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';  # arbitrary methods
          add_header 'Access-Control-Allow-Headers' 'My-First-Header,My-Second-Header,Authorization,Content-Type,Accept,Origin'; # arbitrary headers
          add_header 'Content-Length' 0;
          add_header 'Content-Type' 'text/plain charset=UTF-8';
          return 204;
      }
  }

  Chạy đoạn mãẨn kết quả

  Mở rộng đoạn trích

• bật CORS trên Appache ( .htaccesstệp)

  Hiển thị đoạn mã

  # ------------------------------------------------------------------------------
  # | Cross-domain Ajax requests                                                 |
  # ------------------------------------------------------------------------------
  
  # Enable cross-origin Ajax requests.
  # http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity
  # http://enable-cors.org/
  
  # change * (allow any domain) below to your domain
  Header set Access-Control-Allow-Origin "*"
  Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
  Header always set Access-Control-Allow-Headers "My-First-Header,My-Second-Header,Authorization, content-type, csrf-token"
  Header always set Access-Control-Allow-Credentials "true"

  Chạy đoạn mãẨn kết quả

  Mở rộng đoạn trích