Perkongsian sumber merentas domain CORS kemahiran explanation_javascript terperinci

Ia membolehkan penyemak imbas membuat XMLHttpRequest permintaan ke pelayan silang asal, dengan itu mengatasi had bahawa AJAX hanya boleh digunakan dari asal yang sama.

Artikel ini memperkenalkan mekanisme dalaman CORS secara terperinci.

(Penerangan gambar: Diambil di Taman Oasis di Al Ain, Emiriah Arab Bersatu)

1. Pengenalan

CORS memerlukan sokongan pelayar dan pelayan. Pada masa ini, semua pelayar menyokong fungsi ini, dan pelayar IE tidak boleh lebih rendah daripada IE10.

Keseluruhan proses komunikasi CORS diselesaikan secara automatik oleh penyemak imbas dan tidak memerlukan penyertaan pengguna. Bagi pembangun, tiada perbezaan antara komunikasi CORS dan komunikasi AJAX daripada sumber yang sama, dan kodnya adalah sama. Sebaik sahaja penyemak imbas mendapati bahawa permintaan AJAX adalah asal silang, ia secara automatik akan menambah beberapa maklumat pengepala tambahan, dan kadangkala permintaan tambahan akan dibuat, tetapi pengguna tidak akan merasakannya.

Oleh itu, kunci untuk mencapai komunikasi CORS ialah pelayan. Selagi pelayan melaksanakan antara muka CORS, komunikasi silang asal boleh dilakukan.

2. Dua jenis permintaan

Pelayar membahagikan permintaan CORS kepada dua kategori: permintaan mudah dan permintaan yang tidak begitu mudah.

Selagi dua syarat berikut dipenuhi pada masa yang sama, ia adalah permintaan yang mudah.

(1) Kaedah permintaan ialah salah satu daripada tiga kaedah berikut:

POST KEPALA

(2) Maklumat pengepala HTTP tidak melebihi medan berikut:

AcceptAccept-LanguageContent-LanguageLast-Event-IDContent-Type: terhad kepada tiga nilai application/x-www-form-urlencoded, multipart/form-data, text/plain

Sebarang permintaan yang tidak memenuhi dua syarat di atas pada masa yang sama adalah permintaan yang tidak mudah.

Pelayar mengendalikan kedua-dua permintaan ini secara berbeza.

3. Permintaan mudah 3.1 Proses asas

Untuk permintaan mudah, penyemak imbas mengeluarkan permintaan CORS secara langsung. Khususnya, ia adalah untuk menambah medan Origin pada maklumat pengepala.

Berikut ialah contoh Penyemak imbas mendapati bahawa permintaan AJAX silang asal ini adalah permintaan mudah dan secara automatik menambah medan Origin pada maklumat pengepala.

GET /cors HTTP/1.1Origin: http://api.bob.comHost: api.alice.comAccept-Language: en-USConnection: keep-aliveUser-Agent: Mozilla/5.0...

Dalam maklumat pengepala di atas, medan Origin digunakan untuk menunjukkan sumber mana permintaan ini datang (protokol + nama domain + port). Pelayan memutuskan sama ada untuk bersetuju menerima permintaan berdasarkan nilai ini.

Jika sumber yang ditentukan oleh Origin tidak dalam julat kebenaran, pelayan akan mengembalikan respons HTTP biasa. Apabila penyemak imbas mendapati bahawa maklumat pengepala respons ini tidak mengandungi medan Access-Control-Allow-Origin (lihat di bawah untuk butiran), ia mengetahui bahawa sesuatu telah berlaku dan menyebabkan ralat, yang ditangkap oleh fungsi panggil balik XMLHttpRequest onerror. Ambil perhatian bahawa ralat ini tidak boleh dikenal pasti melalui kod status, kerana kod status respons HTTP mungkin 200.

Jika nama domain yang ditentukan oleh Origin berada dalam julat kebenaran, respons yang dikembalikan oleh pelayan akan mempunyai beberapa lagi medan maklumat pengepala.

Access-Control-Allow-Origin: http://api.bob.comAccess-Control-Allow-Credentials: trueAccess-Control-Expose-Headers: FooBarContent-Type: text/html; charset=utf-8

Antara maklumat pengepala di atas, terdapat tiga medan yang berkaitan dengan permintaan CORS, semuanya bermula dengan Access-Control-.

(1) Access-Control-Allow-Origin

Medan ini diperlukan. Nilainya ialah sama ada nilai medan Origin semasa permintaan, atau *, yang menunjukkan bahawa permintaan daripada mana-mana nama domain diterima.

(2) Akses-Kawalan-Benarkan-Kredential

Medan ini adalah pilihan. Nilainya ialah nilai Boolean yang menunjukkan sama ada untuk membenarkan penghantaran kuki. Secara lalai, kuki tidak disertakan dalam permintaan CORS. Tetapkan kepada true, yang bermaksud bahawa pelayan secara eksplisit membenarkan kuki dimasukkan dalam permintaan dan dihantar ke pelayan. Nilai ini hanya boleh ditetapkan kepada true Jika pelayan tidak mahu penyemak imbas menghantar kuki, padamkan sahaja medan ini.

(3) Capaian-Kawalan-Dedah-Kepala

Medan ini adalah pilihan. Apabila membuat permintaan CORS, kaedah XMLHttpRequest objek getResponseHeader() hanya boleh mendapatkan 6 medan asas: Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, Pragma. Jika anda ingin mendapatkan medan lain, anda mesti menyatakannya dalam Access-Control-Expose-Headers. Contoh di atas menyatakan bahawa getResponseHeader('FooBar') boleh mengembalikan nilai medan FooBar.

3.2 dengan atribut Kredensial

Seperti yang dinyatakan di atas, permintaan CORS tidak menghantar maklumat pengesahan Kuki dan HTTP secara lalai. Jika anda ingin menghantar kuki ke pelayan, anda memerlukan persetujuan pelayan dan nyatakan medan Access-Control-Allow-Credentials.

<code>Access-Control-Allow-Credentials: true</code>

Sebaliknya, pembangun mesti menghidupkan atribut withCredentials dalam permintaan AJAX.

<code>var xhr = new XMLHttpRequest();xhr.withCredentials = true;</code>

否则，即使服务器同意发送Cookie，浏览器也不会发送。或者，服务器要求设置Cookie，浏览器也不会处理。

但是，如果省略withCredentials设置，有的浏览器还是会一起发送Cookie。这时，可以显式关闭withCredentials。

<code>xhr.withCredentials = false;</code>

需要注意的是，如果要发送Cookie，Access-Control-Allow-Origin就不能设为星号，必须指定明确的、与请求网页一致的域名。同时，Cookie依然遵循同源政策，只有用服务器域名设置的Cookie才会上传，其他域名的Cookie并不会上传，且（跨源）原网页代码中的document.cookie也无法读取服务器域名下的Cookie。

四、非简单请求4.1 预检请求

非简单请求是那种对服务器有特殊要求的请求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json。

非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）。

浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。

下面是一段浏览器的JavaScript脚本。

var url = 'http://api.alice.com/cors';var xhr = new XMLHttpRequest();xhr.open('PUT', url, true);xhr.setRequestHeader('X-Custom-Header', 'value');xhr.send();

上面代码中，HTTP请求的方法是PUT，并且发送一个自定义头信息X-Custom-Header。

浏览器发现，这是一个非简单请求，就自动发出一个"预检"请求，要求服务器确认可以这样请求。下面是这个"预检"请求的HTTP头信息。

<code>OPTIONS /cors HTTP/1.1Origin: http://api.bob.comAccess-Control-Request-Method: PUTAccess-Control-Request-Headers: X-Custom-HeaderHost: api.alice.comAccept-Language: en-USConnection: keep-aliveUser-Agent: Mozilla/5.0...</code>

"预检"请求用的请求方法是OPTIONS，表示这个请求是用来询问的。头信息里面，关键字段是Origin，表示请求来自哪个源。

除了Origin字段，"预检"请求的头信息包括两个特殊字段。

（1）Access-Control-Request-Method

该字段是必须的，用来列出浏览器的CORS请求会用到哪些HTTP方法，上例是PUT。

（2）Access-Control-Request-Headers

该字段是一个逗号分隔的字符串，指定浏览器CORS请求会额外发送的头信息字段，上例是X-Custom-Header。

4.2 预检请求的回应

服务器收到"预检"请求以后，检查了Origin、Access-Control-Request-Method和Access-Control-Request-Headers字段以后，确认允许跨源请求，就可以做出回应。

HTTP/1.1 200 OKDate: Mon, 01 Dec 2008 01:15:39 GMTServer: Apache/2.0.61 (Unix)Access-Control-Allow-Origin: http://api.bob.comAccess-Control-Allow-Methods: GET, POST, PUTAccess-Control-Allow-Headers: X-Custom-HeaderContent-Type: text/html; charset=utf-8Content-Encoding: gzipContent-Length: 0Keep-Alive: timeout=2, max=100Connection: Keep-AliveContent-Type: text/plain

上面的HTTP回应中，关键的是Access-Control-Allow-Origin字段，表示<a href="http://api.bob.com">http://api.bob.com</a>可以请求数据。该字段也可以设为星号，表示同意任意跨源请求。

Access-Control-Allow-Origin: *

如果浏览器否定了"预检"请求，会返回一个正常的HTTP回应，但是没有任何CORS相关的头信息字段。这时，浏览器就会认定，服务器不同意预检请求，因此触发一个错误，被XMLHttpRequest对象的onerror回调函数捕获。控制台会打印出如下的报错信息。

XMLHttpRequest cannot load http://api.alice.com.Origin http://api.bob.com is not allowed by Access-Control-Allow-Origin.

服务器回应的其他CORS相关字段如下。

<code>Access-Control-Allow-Methods: GET, POST, PUTAccess-Control-Allow-Headers: X-Custom-HeaderAccess-Control-Allow-Credentials: trueAccess-Control-Max-Age: 1728000</code>

（1）Access-Control-Allow-Methods

该字段必需，它的值是逗号分隔的一个字符串，表明服务器支持的所有跨域请求的方法。注意，返回的是所有支持的方法，而不单是浏览器请求的那个方法。这是为了避免多次"预检"请求。

（2）Access-Control-Allow-Headers

如果浏览器请求包括Access-Control-Request-Headers字段，则Access-Control-Allow-Headers字段是必需的。它也是一个逗号分隔的字符串，表明服务器支持的所有头信息字段，不限于浏览器在"预检"中请求的字段。

（3）Access-Control-Allow-Credentials

该字段与简单请求时的含义相同。

（4）Access-Control-Max-Age

Medan ini adalah pilihan dan digunakan untuk menentukan tempoh sah permintaan prapenerbangan ini, dalam beberapa saat. Dalam keputusan di atas, tempoh sah ialah 20 hari (1728000 saat), yang bermaksud respons dibenarkan untuk dicache selama 1728000 saat (20 hari dalam tempoh ini, tidak perlu mengeluarkan permintaan prapenerbangan lagi).

4.3 Permintaan dan tindak balas biasa pelayar

Setelah pelayan melepasi permintaan "preflight", setiap permintaan CORS biasa daripada penyemak imbas akan sama seperti permintaan mudah, dan akan terdapat Origin medan maklumat pengepala. Respons pelayan juga akan mempunyai Access-Control-Allow-Origin medan maklumat pengepala.

Berikut ialah permintaan CORS biasa penyemak imbas selepas permintaan "preflight".

PUT /cors HTTP/1.1Origin: http://api.bob.comHost: api.alice.comX-Custom-Header: valueAccept-Language: en-USConnection: keep-aliveUser-Agent: Mozilla/5.0...

Medan Origin dalam maklumat pengepala di atas ditambah secara automatik oleh penyemak imbas.

Berikut adalah tindak balas biasa daripada pelayan.

Access-Control-Allow-Origin: http://api.bob.comContent-Type: text/html; charset=utf-8

Dalam maklumat pengepala di atas, medan Access-Control-Allow-Origin mesti disertakan dalam setiap respons.

5. Perbandingan dengan JSONP

CORS digunakan untuk tujuan yang sama seperti JSONP, tetapi lebih berkuasa daripada JSONP.

JSONP hanya menyokong GET permintaan, CORS menyokong semua jenis permintaan HTTP. Kelebihan JSONP ialah ia menyokong pelayar lama dan boleh meminta data daripada tapak web yang tidak menyokong CORS.

(Tamat)