Bagaimana cara kerja header Akses-Kontrol-Bolehkan-Asal?


1154

Rupanya, saya benar-benar salah memahami semantiknya. Saya memikirkan sesuatu seperti ini:

  1. Seorang klien mengunduh kode javascript MyCode.js dari http://siteA- asal .
  2. Header respons MyCode.js berisi Access-Control-Allow-Originhttp://siteB :, yang menurut saya berarti bahwa MyCode.js diizinkan membuat referensi lintas-asal ke situs B.
  3. Klien memicu beberapa fungsionalitas MyCode.js, yang pada gilirannya membuat permintaan http://siteB, yang seharusnya baik-baik saja, meskipun permintaan lintas-asal.

Ya saya salah. Sama sekali tidak bekerja seperti ini. Jadi, saya telah membaca cross-origin resource sharing dan berusaha membaca Cross-Origin Resource Sharing dalam rekomendasi w3c

Satu hal yang pasti - saya masih tidak mengerti bagaimana saya bisa menggunakan header ini.

Saya memiliki kontrol penuh atas situs A dan situs B. Bagaimana cara mengaktifkan kode javascript yang diunduh dari situs A untuk mengakses sumber daya di situs B menggunakan header ini?

PS

Saya tidak ingin menggunakan JSONP.


3
Saya tidak yakin, tapi saya percaya bahwa pengaturan header cara ini memungkinkan kode di situs B untuk menjemput http://siteA/MyCode.js.
pimvdb

6
Tapi bagaimana caranya??? Untuk mendapatkan nilai header kita harus mengambil sumber daya terlebih dahulu, tetapi sumber daya tersebut bersifat lintas asal dan oleh karena itu bukankah browser harus memblokir permintaan di tempat pertama?
tandai

Apa yang Anda gambarkan sebenarnya menyerupai praktik lain, Kebijakan Keamanan Konten
Alex

3
@mark Anda tidak perlu mengambil sumber daya untuk mendapatkan header. Metode HTTP HEADER akan mengembalikan hanya header. Dan dalam kasus CORS, pemeriksaan preflight dilakukan menggunakan metode HTTP OPTIONS yang tidak mengembalikan tubuh juga. jawaban apsillers menjelaskan stackoverflow.com/posts/10636765/revisi ini dengan baik .
Matius

Jawaban:


1446

Access-Control-Allow-Originadalah tajuk CORS (Cross-Origin Resource Sharing) .

Ketika Situs A mencoba untuk mengambil konten dari Situs B, Situs B dapat mengirim Access-Control-Allow-Originheader tanggapan untuk memberi tahu browser bahwa konten halaman ini dapat diakses oleh asal tertentu. ( Asal adalah domain, ditambah skema dan nomor port .) Secara default, halaman Situs B tidak dapat diakses oleh asal lain ; menggunakan Access-Control-Allow-Originheader membuka pintu untuk akses lintas-asal dengan asal-usul permintaan yang spesifik.

Untuk setiap sumber daya / halaman yang ingin diakses Situs B untuk Situs A, Situs B harus melayani halaman-halamannya dengan tajuk respons:

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

Browser modern tidak akan langsung memblokir permintaan lintas domain. Jika Situs A meminta halaman dari Situs B, browser akan benar-benar mengambil halaman yang diminta pada tingkat jaringan dan memeriksa apakah header responsnya mendaftar Situs A sebagai domain pemohon yang diizinkan. Jika Site B belum mengindikasikan bahwa Situs A diperbolehkan untuk mengakses halaman ini, browser akan memicu XMLHttpRequest's erroracara dan menyangkal data respon terhadap kode JavaScript meminta.

Permintaan tidak sederhana

Apa yang terjadi pada tingkat jaringan bisa sedikit lebih kompleks daripada yang dijelaskan di atas. Jika permintaan tersebut adalah permintaan "tidak sederhana" , browser pertama-tama mengirimkan permintaan OPSI "preflight" tanpa data, untuk memverifikasi bahwa server akan menerima permintaan tersebut. Permintaan tidak sederhana ketika salah satu (atau keduanya):

  • menggunakan kata kerja HTTP selain GET atau POST (mis. PUT, DELETE)
  • menggunakan header permintaan yang tidak sederhana; satu-satunya header permintaan sederhana adalah:
    • Accept
    • Accept-Language
    • Content-Language
    • Content-Type(ini hanya sederhana jika nilainya application/x-www-form-urlencoded, multipart/form-dataatau text/plain)

Jika server menanggapi preflight OPSI dengan tajuk respons yang sesuai ( Access-Control-Allow-Headersuntuk tajuk yang tidak sederhana, Access-Control-Allow-Methodsuntuk kata kerja yang tidak sederhana) yang cocok dengan kata kerja yang tidak sederhana dan / atau tajuk yang tidak sederhana, maka browser mengirimkan permintaan yang sebenarnya.

Mengandaikan bahwa Situs A ingin mengirim permintaan PUT untuk /somePage, dengan non-sederhana Content-Typenilai application/json, browser pertama akan mengirim permintaan preflight:

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

Perhatikan itu Access-Control-Request-Methoddan Access-Control-Request-Headersditambahkan oleh browser secara otomatis; Anda tidak perlu menambahkannya. Preferensi OPSI ini mendapatkan tajuk respons yang berhasil:

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

Saat mengirim permintaan aktual (setelah preflight dilakukan), perilaku itu identik dengan bagaimana permintaan sederhana ditangani. Dengan kata lain, permintaan non-sederhana yang preflight-nya berhasil diperlakukan sama dengan permintaan sederhana (yaitu, server masih harus mengirim Access-Control-Allow-Originlagi untuk tanggapan yang sebenarnya).

Browser mengirim permintaan aktual:

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

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

Dan server mengirim kembali sebuah Access-Control-Allow-Origin, seperti halnya permintaan sederhana:

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

Lihat Memahami XMLHttpRequest atas CORS untuk informasi lebih lanjut tentang permintaan yang tidak sederhana.


4
Tetapi MyCode.js tidak dapat meraih situs B sejak awal! Bagaimana header ini sampai pada klien? BTW, pujian untuk glider kehidupan ringan di avatar.
tandai

8
Saya mengedit dengan klarifikasi: browser benar-benar melakukan pengambilan jaringan di situs B untuk memeriksa Access-Control-Allow-Originheader, tetapi mungkin tidak memberikan respons terhadap kode JS di situs A jika header tidak mengizinkan situs A untuk memilikinya. (PS Terima kasih :))
apsillers

2
Memang, saya tidak melihat catatan unduhan di Fiddler, kecuali permintaan lintas-asal disetujui. Menarik ...
tandai

23
@ Jwan622 Pertanyaan mendasar " mengapa? " Seperti itu mungkin di luar jangkauan untuk jawaban khusus ini, yang hanya tentang aturan & mekanika. Pada dasarnya, peramban memungkinkan Anda , manusia yang duduk di depan komputer, melihat sumber daya apa pun dari sumber mana pun. Itu melarang skrip (yang dapat ditulis oleh siapa saja) dari sumber membaca dari asal yang berbeda dari asal halaman menjalankan skrip. Beberapa pertanyaan terkait adalah programmer.stackexchange.com/q/216605 dan Apa model ancaman untuk kebijakan asal yang sama?
apsillers

3
Jika menggunakan otentikasi, Access-Control-Allow-Origintidak menerima *di beberapa browser (FF dan Chrome AFAIK). Jadi dalam hal ini Anda harus menentukan nilai dari Originheader. Semoga ini bisa membantu seseorang.
Zsolti

123

Cross-Origin Resource Sharing - CORS(permintaan AJAX Cross-Domain AKA) adalah masalah yang sebagian besar pengembang web mungkin temui, menurut Same-Origin-Policy, browser membatasi JavaScript klien dalam kotak pasir keamanan, biasanya JS tidak dapat berkomunikasi secara langsung dengan server jarak jauh dari domain yang berbeda. Di masa lalu pengembang menciptakan banyak cara rumit untuk mencapai permintaan sumber daya Lintas-Domain, cara yang paling umum digunakan adalah:

  1. Gunakan Flash / Silverlight atau sisi server sebagai "proxy" untuk berkomunikasi dengan remote.
  2. JSON Dengan Padding ( JSONP ).
  3. Sematkan server jauh dalam iframe dan berkomunikasi melalui fragmen atau window.name, lihat di sini .

Cara-cara rumit tersebut memiliki lebih atau kurang beberapa masalah, misalnya JSONP dapat mengakibatkan lubang keamanan jika pengembang hanya "mengevaluasi" itu, dan # 3 di atas, meskipun berfungsi, kedua domain harus membangun kontrak yang ketat antara satu sama lain, tidak fleksibel atau elegan MENURUT OPINI SAYA:)

W3C telah memperkenalkan Cross-Origin Resource Sharing (CORS) sebagai solusi standar untuk memberikan cara standar yang aman, fleksibel dan direkomendasikan untuk menyelesaikan masalah ini.

Mekanisme

Dari level tinggi, kita dapat menganggap CORS adalah kontrak antara panggilan AJAX klien dari domain A dan halaman yang dihosting di domain B, permintaan / respons Cross-Origin tipikal adalah:

Header permintaan DomainA AJAX

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 

Header respons 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

Bagian biru yang saya tandai di atas adalah fakta kernal, "Asal" header permintaan "menunjukkan di mana permintaan lintas-asal atau permintaan preflight berasal dari", header respons "Akses-Kontrol-Bolehkan-Asal" menunjukkan bahwa laman ini memungkinkan permintaan jarak jauh dari DomainA (jika nilainya * mengindikasikan memungkinkan permintaan jarak jauh dari domain apa pun).

Seperti yang saya sebutkan di atas, W3 merekomendasikan browser untuk mengimplementasikan " permintaan preflight " sebelum mengirimkan permintaan HTTP Cross-Origin yang sebenarnya, singkatnya itu adalah OPTIONSpermintaan HTTP :

OPTIONS DomainB.com/foo.aspx HTTP/1.1

Jika foo.aspx mendukung OPTIONS HTTP verb, itu mungkin mengembalikan respons seperti di bawah ini:

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

Hanya jika responsnya berisi "Akses-Kontrol-Bolehkan-Asal" DAN nilainya adalah "*" atau berisi domain yang mengirimkan permintaan CORS, dengan memenuhi syarat ini, browser akan mengirimkan permintaan Cross-Domain yang sebenarnya, dan menyimpan hasilnya. di " Preflight-Result-Cache ".

Saya membuat blog tentang CORS tiga tahun lalu: permintaan HTTP Cross-Origin AJAX


Jawaban ini membuat saya sadar mengapa saya tiba-tiba mendapatkan masalah tanpa menggunakan header ini untuk permintaan POST dan GET. Saya tidak sengaja membuka file index.html langsung dari disk, jadi URL yang diakses klien di node.js dianggap sebagai lintas-domain, sementara itu hanya berjalan di localhost. Mengakses melalui URL (seperti biasanya) "memecahkan" masalah saya ...
LuqJensen

Apakah domain di jaringan eksternal dapat berkomunikasi dengan domain di jaringan internal?
Si8

68

Pertanyaan agak terlalu tua untuk dijawab, tetapi saya memposting ini untuk referensi di masa depan untuk pertanyaan ini.

Menurut ini Mozilla Developer artikel Jaringan,

Sumber daya membuat permintaan HTTP lintas-asal ketika permintaan sumber daya dari domain yang berbeda, atau port dari yang sumber daya itu sendiri melayani.

masukkan deskripsi gambar di sini

Sebuah halaman HTML dilayani dari http://domain-a.commembuat <img>permintaan src untuk http://domain-b.com/image.jpg.
Banyak halaman di web saat ini memuat sumber daya seperti stylesheet CSS , gambar , dan skrip dari domain terpisah (sehingga harus keren).

Kebijakan Asal-Sama

Untuk alasan keamanan, browser membatasi permintaan HTTP lintas-asal yang dimulai dari dalam skrip .
Misalnya, XMLHttpRequestdan Fetchikuti kebijakan asal-sama .
Jadi, aplikasi web menggunakan XMLHttpRequestatau Fetchhanya bisa membuat permintaan HTTP ke domainnya sendiri .

Cross-Origin Resource Sharing (CORS)

Untuk meningkatkan aplikasi web, pengembang meminta vendor peramban untuk mengizinkan permintaan lintas domain.

The Cross-Origin Resource Sharing (CORS) mekanisme memberi server web kontrol akses lintas-domain , yang memungkinkan aman transfer data cross-domain.
Browser modern menggunakan CORS dalam wadah API - seperti XMLHttpRequestatauFetch - untuk mengurangi risiko permintaan HTTP lintas-asal.

Cara kerja CORS ( Access-Control-Allow-Origintajuk)

Wikipedia :

Standar CORS menjelaskan header HTTP baru yang menyediakan cara browser dan server untuk meminta URL jarak jauh hanya ketika mereka memiliki izin.

Meskipun beberapa validasi dan otorisasi dapat dilakukan oleh server, umumnya tanggung jawab browser untuk mendukung tajuk ini dan menghormati pembatasan yang mereka lakukan.

Contoh

  1. Browser mengirim OPTIONSpermintaan dengan Origin HTTPtajuk.

    Nilai header ini adalah domain yang melayani halaman induk. Saat halaman dari http://www.example.comupaya mengakses data pengguna service.example.com, tajuk permintaan berikut akan dikirim ke service.example.com:

    Asal: http://www.example.com

  2. Server di service.example.comdapat merespons dengan:

    • Sebuah Access-Control-Allow-Origin(Ação) header respon yang menunjukkan asal situs diperbolehkan.
      Sebagai contoh:

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

    • Halaman kesalahan jika server tidak mengizinkan permintaan lintas asal

    • Sebuah Access-Control-Allow-Origin(Ação) sundulan dengan wildcard yang memungkinkan semua domain:

      Access-Control-Allow-Origin: *


1
Cara mengatur tidak ada yang diizinkan untuk acees beberapa hal sepertiAccess-Control-Allow-Origin:null
Subin Chalil

2
Ketika saya tidak ingin mengizinkan siapa pun mengakses sumber daya saya melalui CORS, nilai apa yang harus saya tetapkan Access-Control-Allow-Origin? Maksud saya negasi dariAccess-Control-Allow-Origin: *
Subin Chalil

4
Hanya saja, jangan mengatur apa pun, untuk tujuan itu
Pmpr

23

Setiap kali saya mulai berpikir tentang CORS, intuisi saya tentang situs mana yang menjadi header tidak benar, seperti yang Anda jelaskan dalam pertanyaan Anda. Bagi saya, ada baiknya memikirkan tentang tujuan kebijakan asal yang sama.

Tujuan dari kebijakan asal yang sama adalah untuk melindungi Anda dari JavaScript jahat di siteA.com mengakses informasi pribadi yang Anda pilih untuk dibagikan hanya dengan siteB.com. Tanpa kebijakan asal yang sama, JavaScript yang ditulis oleh penulis siteA.com dapat membuat browser Anda membuat permintaan ke siteB.com, menggunakan cookie autentikasi Anda untuk siteB.com. Dengan cara ini, siteA.com dapat mencuri informasi rahasia yang Anda bagikan dengan siteB.com.

Terkadang Anda perlu bekerja lintas domain, yang merupakan tempat CORS masuk. CORS melonggarkan kebijakan asal yang sama untuk domainB.com, menggunakan Access-Control-Allow-Origin header untuk mendaftar domain lain (domainA.com) yang dipercaya menjalankan JavaScript yang dapat berinteraksi dengan domainA. com.

Untuk memahami domain mana yang harus melayani tajuk CORS, pertimbangkan ini. Anda mengunjungi malicious.com, yang berisi beberapa JavaScript yang mencoba membuat permintaan lintas domain ke mybank.com. Seharusnya terserah mybank.com, bukan malicious.com, untuk memutuskan apakah itu menetapkan header CORS yang mengendurkan kebijakan asal yang sama yang memungkinkan JavaScript dari malicious.com berinteraksi dengannya. Jika malicous.com dapat menetapkan tajuk CORS sendiri yang memungkinkan akses JavaScriptnya sendiri ke mybank.com, ini akan sepenuhnya membatalkan kebijakan asal yang sama.

Saya pikir alasan intuisi buruk saya adalah sudut pandang yang saya miliki ketika mengembangkan sebuah situs. Ini adalah situs saya , dengan semua JavaScript saya , oleh karena itu tidak melakukan apa pun yang berbahaya dan harus terserah saya untuk menentukan situs lain mana yang dapat berinteraksi dengan JavaScript saya . Padahal sebenarnya saya harus berpikir yang lain situs JavaScript mencoba untuk berinteraksi dengan situs saya dan harus saya gunakan CORS untuk memungkinkan mereka?


1
Mengingat paragraf 2, apakah Anda memiliki siteA, siteB mundur dalam paragraf 3? Saya bisa saja salah paham, tetapi paragraf sebelumnya sepertinya menyiratkan siteA-nya yang menjalankan JS yang dimaksud?
cellepo

11

1. Seorang klien mengunduh kode javascript MyCode.js dari http: // siteA - asal.

Kode yang melakukan pengunduhan - tag skrip html Anda atau xhr dari javascript atau apa pun - berasal dari, katakanlah, http: // siteZ . Dan, ketika browser meminta MyCode.js, ia mengirim header Origin: yang bertuliskan "Origin: http: // siteZ ", karena itu dapat melihat bahwa Anda meminta ke siteA dan siteZ! = SiteA. (Anda tidak dapat menghentikan atau mengganggu ini.)

2. Header respons MyCode.js berisi Access-Control-Allow-Origin: http: // siteB , yang menurut saya berarti MyCode.js diizinkan membuat referensi lintas-asal ke situs B.

tidak. Artinya, Hanya siteB yang diizinkan melakukan permintaan ini. Jadi permintaan Anda untuk MyCode.js dari siteZ malah mendapatkan kesalahan, dan browser biasanya tidak memberi Anda apa-apa. Tetapi jika Anda membuat server Anda mengembalikan ACAO: siteZ, Anda akan mendapatkan MyCode.js. Atau jika ia mengirim '*', itu akan berhasil, itu akan membiarkan semua orang masuk. Atau jika server selalu mengirim string dari Origin: header ... tapi ... untuk keamanan, jika Anda takut akan peretas , server Anda seharusnya hanya mengizinkan asal pada daftar pendek, yang diizinkan untuk membuat permintaan tersebut.

Kemudian, MyCode.js berasal dari siteA. Ketika membuat permintaan ke situs B, semuanya berasal dari silang, browser mengirim Asal: situsA, dan situsB harus mengambil situsA, mengenalinya di daftar pendek pemohon yang diizinkan, dan mengirim kembali ACAO: situsA. Hanya dengan demikian browser akan membiarkan skrip Anda mendapatkan hasil dari permintaan tersebut.


10

Menggunakan Bereaksi dan Aksioma , bergabunglah dengan tautan proxy ke URL dan tambahkan header seperti yang ditunjukkan di bawah ini

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

Hanya dengan menambahkan tautan Proksi akan berfungsi, tetapi juga dapat membuang kesalahan untuk Tidak Akses lagi. Oleh karena itu lebih baik menambahkan header seperti yang ditunjukkan di bawah ini.

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

PERINGATAN: Tidak untuk digunakan dalam Produksi

Ini hanya perbaikan cepat, jika Anda kesulitan mengapa Anda tidak bisa mendapatkan respons, Anda BISA menggunakan ini. Tapi sekali lagi itu bukan jawaban terbaik untuk produksi.

Mendapat beberapa downvotes dan itu benar-benar masuk akal, saya seharusnya menambahkan peringatan itu sejak lama.


19
Tolong jangan lakukan ini. Menggunakan tautan proxy seperti menyerahkan cookie pengguna ke perantara. Seharusnya IMHO ilegal
anthonymonori

ini berguna bagi saya! Kecuali daripada menggunakan * (yang memiliki masalah keamanan), saya membatasi Kontrol Akses ke alamat persis yang saya gunakan untuk belajar ... dalam kasus saya ' reqres.in/api/register '
C-Note187

9

Jika Anda hanya ingin menguji aplikasi lintas domain di mana browser memblokir permintaan Anda, maka Anda bisa membuka browser Anda dalam mode tidak aman dan menguji aplikasi Anda tanpa mengubah kode Anda dan tanpa membuat kode Anda tidak aman. Dari MAC OS Anda dapat melakukan ini dari terminal:

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

9

Jika Anda menggunakan PHP, coba tambahkan kode berikut di awal file php:

Jika Anda menggunakan localhost, coba ini:

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

Jika Anda menggunakan domain eksternal seperti server, coba ini:

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

7

saya bekerja dengan express 4 dan node 7.4 dan angular, saya punya masalah yang sama saya bantu ini:
a) sisi server: di file app.js saya memberikan header untuk semua respons seperti:

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();
 });  

ini harus ada sebelum semua router .
Saya melihat banyak menambahkan header ini:

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

tetapi saya tidak memerlukan itu,
b) sisi klien: dalam mengirim ajax Anda perlu menambahkan: "withCredentials: true," seperti:

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

semoga berhasil.


res.header('Access-Control-Allow-Origin', req.headers.origin);sama denganres.header('Access-Control-Allow-Origin', '*');
The Aelfinn

4

Untuk berbagi asal silang, tetapkan tajuk: 'Access-Control-Allow-Origin':'*';

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

Node: app.use('Access-Control-Allow-Origin':'*');

Ini akan memungkinkan untuk berbagi konten untuk domain yang berbeda.


4

Dalam Python saya telah menggunakan Flask-CORSperpustakaan dengan sukses besar. Itu membuat berurusan dengan CORS sangat mudah dan tidak menyakitkan. Saya menambahkan beberapa kode dari dokumentasi perpustakaan di bawah ini.

Menginstal:

$ pip install -U flask-cors

Contoh sederhana yang memungkinkan CORS untuk semua domain di semua rute:

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

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

Untuk contoh yang lebih spesifik lihat dokumentasi. Saya telah menggunakan contoh sederhana di atas untuk mengatasi masalah CORS dalam aplikasi ion yang saya bangun yang harus mengakses server labu terpisah.


4

Dari pengalaman saya sendiri, sulit untuk menemukan penjelasan sederhana mengapa CORS bahkan menjadi perhatian.

Setelah Anda mengerti mengapa itu ada di sana, tajuk dan diskusi menjadi jauh lebih jelas. Saya akan mencobanya dalam beberapa baris.


Ini semua tentang cookie. Cookie disimpan di klien dengan domain mereka.

Contoh cerita: Di komputer Anda, ada cookie untuk yourbank.com. Mungkin sesi Anda ada di sana.

Poin kunci: Ketika klien membuat permintaan ke server, itu akan mengirim cookie yang disimpan di bawah domain tempat klien aktif.

Anda masuk di browser Anda ke yourbank.com. Anda meminta untuk melihat semua akun Anda. yourbank.commenerima tumpukan cookie dan mengirimkan kembali responsnya (akun Anda).

Jika klien lain membuat permintaan asal silang ke server, cookie tersebut dikirimkan bersama, seperti sebelumnya. Ruh roh.

Anda telusuri malicious.com. Malicious membuat banyak permintaan ke berbagai bank, termasuk yourbank.com.

Karena cookie divalidasi seperti yang diharapkan, server akan mengesahkan respons.

Cookie itu dikumpulkan dan dikirim - dan sekarang, malicious.commendapat tanggapan dari yourbank.

Astaga.


Jadi sekarang, beberapa pertanyaan dan jawaban menjadi jelas:

  • "Kenapa kita tidak memblokir browser saja dari melakukan itu?" Ya. CORS.
  • "Bagaimana kita mengatasinya?" Mintalah server memberi tahu permintaan bahwa CORS baik-baik saja.

3

Cukup tempel kode berikut di file web.config Anda.

Tercatat, Anda harus menempelkan kode berikut di bawah <system.webServer>tag

    <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>  

0

Header respons Access-Control-Allow-Origin menunjukkan apakah respons dapat dibagi dengan meminta kode dari asal yang diberikan.

Header type Response       header
Forbidden header name      no

Respons yang memberi tahu browser untuk mengizinkan kode dari asal mana pun untuk mengakses sumber daya akan mencakup yang berikut:

Access-Control-Allow-Origin: *

Untuk info lebih lanjut, kunjungi di sini ....


0

Nginx dan Appache

Sebagai tambahan untuk jawaban apsillers, saya ingin menambahkan grafik wiki yang menunjukkan kapan permintaan sederhana atau tidak (dan permintaan pra-penerbangan OPSI dikirim atau tidak)

Masukkan deskripsi gambar di sini

Untuk permintaan sederhana (mis. Gambar hotlinking ) Anda tidak perlu mengubah file konfigurasi server Anda tetapi Anda dapat menambahkan header dalam aplikasi (di-host di server, misalnya dalam php) seperti Melvin Guerrero menyebutkan dalam jawabannya - tetapi ingat : jika Anda menambahkan penuh header kor di server Anda (config) dan pada saat yang sama Anda mengizinkan kor sederhana pada aplikasi (mis. php) ini tidak akan berfungsi sama sekali.

Dan berikut adalah konfigurasi untuk dua server populer

  • nyalakan CORS di Nginx ( nginx.conffile)

  • nyalakan CORS pada Appache ( .htaccessfile)

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.