So implementieren Sie domänenübergreifende Ajax-Anfragen mithilfe von CORS über das Koa2-Framework

In diesem Artikel wird hauptsächlich das Koa2-Framework zur Verwendung von CORS zur Vervollständigung domänenübergreifender Ajax-Anfragen vorgestellt. Jetzt teile ich es mit Ihnen und gebe es als Referenz.

Es gibt viele Möglichkeiten, domänenübergreifende Ajax-Anfragen zu implementieren. Eine davon ist die Verwendung von CORS. Der Schlüssel zu dieser Methode besteht darin, sie auf der Serverseite zu konfigurieren.

In diesem Artikel wird nur die grundlegendste Konfiguration erläutert, die eine normale domänenübergreifende Ajax-Antwort durchführen kann (ich weiß nicht, wie man eine detaillierte Konfiguration durchführt).

CORS unterteilt Anfragen in einfache Anfragen und nicht einfache Anfragen. Man kann einfach davon ausgehen, dass einfache Anfragen Get- und Post-Anfragen ohne zusätzliche Anfrageheader sind, und wenn es sich um eine Post-Anfrage handelt, kann das Anfrageformat nicht angewendet werden /json (da ich in diesem Bereich kein tiefes Verständnis habe. Wenn ein Fehler auftritt, hoffe ich, dass jemand auf den Fehler hinweisen und Änderungen vorschlagen kann). Der Rest, Put- und Post-Anfragen, Anfragen mit Content-Type application/json und Anfragen mit benutzerdefinierten Anfrage-Headern sind nicht einfache Anfragen.

Die Konfiguration einer einfachen Anfrage ist sehr einfach. Wenn Sie nur die Antwort vervollständigen müssen, um das Ziel zu erreichen, müssen Sie nur den Access-Control-Allow-Origin im Antwortheader konfigurieren.

Wenn wir auf den Domänennamen http://127.0.0.1:3001 unter dem Domänennamen http://localhost:3000 zugreifen möchten. Sie können die folgende Konfiguration vornehmen:

app.use(async (ctx, next) => {
 ctx.set('Access-Control-Allow-Origin', 'http://localhost:3000');
 await next();
});

Dann verwenden Sie Ajax, um eine einfache Anfrage zu initiieren, beispielsweise eine Post-Anfrage, und Sie können problemlos die richtige Antwort vom Server erhalten.

Der experimentelle Code lautet wie folgt:

$.ajax({
  type: 'post',
  url: 'http://127.0.0.1:3001/async-post'
 }).done(data => {
  console.log(data);
})

Serverseitiger Code:

router.post('/async-post',async ctx => {
 ctx.body = {
 code: "1",
 msg: "succ"
 }
});

Dann können Sie die richtigen Antwortinformationen erhalten.

Wenn Sie sich zu diesem Zeitpunkt die Header-Informationen der Anfrage und Antwort ansehen, werden Sie feststellen, dass der Anfrage-Header einen zusätzlichen Ursprung hat (es gibt auch einen Verweis auf die URL-Adresse der Anfrage) und die Der Antwortheader verfügt über einen zusätzlichen Access-Control-Allow-Origin.

Sie können jetzt einfache Anfragen senden, Sie benötigen jedoch noch andere Konfigurationen, um nicht einfache Anfragen zu senden.

Wenn eine nicht einfache Anfrage zum ersten Mal gestellt wird, werden tatsächlich zwei Anfragen ausgegeben. Die erste ist eine Preflight-Anfrage. Die Anfragemethode dieser Anfrage bestimmt, ob dies der Fall ist Die Anfrage wird übergeben. Ob die Art der nicht einfachen Anfrage erfolgreich beantwortet werden kann.

Um diese Anfrage vom Typ OPTIONS auf dem Server abzugleichen, müssen Sie eine entsprechende Middleware erstellen und eine Antwort geben, damit diese Vorprüfung bestanden werden kann.

app.use(async (ctx, next) => {
 if (ctx.method === 'OPTIONS') {
 ctx.body = '';
 }
 await next();
});

Auf diese Weise kann die OPTIONS-Anfrage passieren.

Wenn Sie den Anforderungsheader der Preflight-Anfrage überprüfen, werden Sie feststellen, dass es zwei weitere Anforderungsheader gibt.

Access-Control-Request-Method: PUT
Origin: http://localhost:3000

Verhandeln Sie mit dem Server über diese beiden Header-Informationen, um zu sehen, ob er die Antwortbedingungen des Servers erfüllt.

Da der Anforderungsheader zwei weitere Informationen enthält, sollte der Antwortheader natürlich zwei entsprechende Informationen enthalten:

Access-Control-Allow-Origin: http://localhost:3000
Access-Control-Allow-Methods: PUT,DELETE,POST,GET

Die erste Information und Herkunft Das Gleiche gilt also. Die zweite Information entspricht der Access-Controll-Request-Method. Wenn die Request-Methode in der vom Server zugelassenen Antwortmethode enthalten ist, wird diese Information ebenfalls übergeben. Beide Einschränkungen sind erfüllt, sodass die Anfrage erfolgreich initiiert werden kann.

Bis zu diesem Zeitpunkt ist es gleichbedeutend damit, nur die Vorprüfung durchzuführen und nicht die eigentliche Anfrage zu senden.

Natürlich hat die eigentliche Anfrage auch erfolgreich die Antwort erhalten, und der Antwortheader lautet wie folgt (ohne unwichtige Teile)

Access-Control-Allow-Origin: http://localhost:3000
Access-Control-Allow-Methods: PUT,DELETE,POST,GET

Der Anforderungsheader lautet wie folgt:

Origin: http://localhost:3000

Das ist offensichtlich. Die Antwort-Header-Informationen sind das, was wir auf dem Server festlegen, also ist das der Grund.

Der Client muss den Access-Control-Request-Method-Anfrageheader nicht senden, da er gerade vorab überprüft wurde.

Der Code für dieses Beispiel lautet wie folgt:

$.ajax({
   type: 'put',
   url: 'http://127.0.0.1:3001/put'
  }).done(data => {
   console.log(data);
});

Servercode:

app.use(async (ctx, next) => {
  ctx.set('Access-Control-Allow-Origin', 'http://localhost:3000');
  ctx.set('Access-Control-Allow-Methods', 'PUT,DELETE,POST,GET');
  await next();
});

An diesem Punkt haben wir die Grundkonfiguration abgeschlossen, die eine domänenübergreifende Ajax-Antwort korrekt durchführen kann , und es gibt einige, die noch etwas weiter konfiguriert werden können.

Beispielsweise werden bisher bei jeder nicht einfachen Anfrage tatsächlich zwei Anfragen ausgegeben, eine für den Preflight und eine für eine echte Anfrage, was zu einem Leistungsverlust führt. Um keine Preflight-Anfrage zu senden, können Sie die folgenden Antwortheader konfigurieren.

Access-Control-Max-Age: 86400

Die Bedeutung dieses Antwortheaders besteht darin, eine relative Zeit ab dem Zeitpunkt festzulegen, an dem die nicht einfache Anforderung den Test auf der Serverseite besteht, wenn die verstrichene Zeit in Millisekunden kleiner als Access-Control-Max ist. Alter: Es ist kein Preflight erforderlich und Sie können direkt eine Anfrage senden.

Natürlich gibt es für einfache Anfragen keinen Preflight, daher ist dieser Code für einfache Anfragen bedeutungslos.

Der aktuelle Code lautet wie folgt:

app.use(async (ctx, next) => {
 ctx.set('Access-Control-Allow-Origin', 'http://localhost:3000');
 ctx.set('Access-Control-Allow-Methods', 'PUT,DELETE,POST,GET');
 ctx.set('Access-Control-Max-Age', 3600 * 24);
 await next();
});

Bisher können Sie auf domänenübergreifende Ajax-Anfragen antworten, aber die Cookies unter dieser Domäne werden nicht im Anfrageheader übertragen. Wenn Sie das Cookie zum Server bringen und dem Server erlauben möchten, das Cookie weiter zu setzen, ist eine weitere Konfiguration erforderlich.

Um die spätere Erkennung zu erleichtern, setzen wir vorab zwei Cookies unter dem Domainnamen http://127.0.0.1:3001. Achten Sie darauf, das Cookie nicht versehentlich auf Chinesisch zu setzen (ich habe es gerade auf Chinesisch eingestellt und es hat einen Fehler gemeldet. Ich konnte die Fehlerursache lange nicht finden)

Dann müssen wir es tun Führen Sie zwei Schritte aus. Der erste Schritt besteht darin, den Antwortheader Access-Control-Allow auf true zu setzen und dann das withCredentials-Attribut des xhr-Objekts auf true zu setzen.

Der Client-Code lautet wie folgt:

$.ajax({
   type: 'put',
   url: 'http://127.0.0.1:3001/put',
   data: {
    name: '黄天浩',
    age: 20
   },
   xhrFields: {
    withCredentials: true
   }
  }).done(data => {
   console.log(data);
  });

Der Server-Code lautet wie folgt:

app.use(async (ctx, next) => {
  ctx.set('Access-Control-Allow-Origin', 'http://localhost:3000');
  ctx.set('Access-Control-Allow-Methods', 'PUT,DELETE,POST,GET');
  ctx.set('Access-Control-Allow-Credentials', true);
  await next();
});

这时就可以带着cookie到服务器了，并且服务器也可以对cookie进行改动。但是cookie仍是http://127.0.0.1:3001域名下的cookie，无论怎么操作都在该域名下，无法访问其他域名下的cookie。

现在为止CORS的基本功能已经都提到过了。

一开始我不知道怎么给Access-Control-Allow-Origin，后来经人提醒，发现可以写一个白名单数组，然后每次接到请求时判断origin是否在白名单数组中，然后动态的设置Access-Control-Allow-Origin，代码如下：

app.use(async (ctx, next) => {
 if (ctx.request.header.origin !== ctx.origin && whiteList.includes(ctx.request.header.origin)) {
  ctx.set('Access-Control-Allow-Origin', ctx.request.header.origin);
  ctx.set('Access-Control-Allow-Methods', 'PUT,DELETE,POST,GET');
  ctx.set('Access-Control-Allow-Credentials', true);
  ctx.set('Access-Control-Max-Age', 3600 * 24);
 }
 await next();
});

这样就可以不用*通配符也可匹配多个origin了。

注意：ctx.origin与ctx.request.header.origin不同，ctx.origin是本服务器的域名，ctx.request.header.origin是发送请求的请求头部的origin，二者不要混淆。

最后，我们再稍微调整一下自定义的中间件的结构，防止每次请求都返回Access-Control-Allow-Methods以及Access-Control-Max-Age，这两个响应头其实是没有必要每次都返回的，只是第一次有预检的时候返回就可以了。

调整后顺序如下：

app.use(async (ctx, next) => {
 if (ctx.request.header.origin !== ctx.origin && whiteList.includes(ctx.request.header.origin)) {
  ctx.set('Access-Control-Allow-Origin', ctx.request.header.origin);
  ctx.set('Access-Control-Allow-Credentials', true);
 }
 await next();
});

app.use(async (ctx, next) => {
 if (ctx.method === 'OPTIONS') {
  ctx.set('Access-Control-Allow-Methods', 'PUT,DELETE,POST,GET');
  ctx.set('Access-Control-Max-Age', 3600 * 24);
  ctx.body = '';
 }
 await next();
});

这样就减少了多余的响应头。

上面是我整理给大家的，希望今后会对大家有帮助。

相关文章：

webpack打包js的方法

vue 简单自动补全的输入框的示例

angular5 httpclient的示例实战

Das obige ist der detaillierte Inhalt vonSo implementieren Sie domänenübergreifende Ajax-Anfragen mithilfe von CORS über das Koa2-Framework. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!