How to use CORS of the Koa2 framework to complete cross-domain ajax requests

This time I will show you how to use the CORS of the Koa2 framework to complete cross-domain ajax requests, and how to use the CORS of the Koa2 framework to complete cross-domain ajax requests. take a look. There are many ways to implement cross-domain ajax requests, one of which is to use CORS, and the key to this method is to configure it on the server side.

This article only explains the most basic configuration that can complete normal cross-domain ajax response (I don’t know how to do in-depth configuration).

CORS divides requests into simple requests and non-simple requests. It can be simply thought that simple requests are get and

without additional request headers, and if it is a post request , the request format cannot be application/json (because I don’t have a deep understanding of this area. If there is an error, I hope someone can point out the error and suggest modifications). The rest, put and post requests, requests with Content-Type application/json, and requests with custom request headers are non-simple requests. The configuration of a simple request is very simple. If you only need to complete the response to achieve the goal, you only need to configure the Access-Control-Allow-Origin in the response header.

If we want to access the http://127.0.0.1:3001 domain name under the http://localhost:3000 domain name. You can make the following configuration:

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

Then use ajax to initiate a simple request, such as a post request, and you can easily get the correct response from the server.

The experimental code is as follows:

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

Server-side code:

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

Then you can get the correct response information.

If you look at the header information of the request and response at this time, you will find that the request header has an extra origin (there is also a referer for the URL address of the request), and the response header has an extra Access- Control-Allow-Origin.

Now you can send simple requests, but you still need other configurations to send non-simple requests.

When a non-simple request is issued for the first time, two requests will actually be issued. The first one is a preflight request. The

of this request is OPTIONS. This request Whether it passes or not determines whether this type of non-simple request can be successfully responded to. In order to match this OPTIONS type request on the server, you need to make a

to match it and give a response so that this pre-check can pass.

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

If you check the request header of the preflight request, you will find that there are two more request headers.

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

Negotiate with the server through these two header information to see if the server response conditions are met.

It’s easy to understand. Since the request header has two more pieces of information, the response header should naturally have two corresponding pieces of information. The two pieces of information are as follows:

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

The first piece of information and origin The same therefore passes. The second piece of information corresponds to Access-Controll-Request-Method. If the request method is included in the response method allowed by the server, this piece of information will also pass. Both constraints are met, so the request can be successfully initiated.

So far, it is equivalent to only completing the pre-check and not sending the real request yet.

Of course the real request also successfully obtained the response, and the response header is as follows (omitting unimportant parts)

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

The request header is as follows:

Origin: http://localhost:3000

This is very obvious, The response header information is what we set on the server, so that's why.

The client does not need to send the Access-Control-Request-Method request header because it has been pre-checked just now.

The code for this example is as follows:

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

Server code:

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

At this point we have completed the basic configuration that can correctly perform cross-domain ajax response, and some can be further configured. s things.

For example, so far, every non-simple request will actually issue two requests, one for preflight and one for real request, which results in a loss of performance. In order not to send a preflight request, you can configure the following response headers.

Access-Control-Max-Age: 86400

这个响应头的意义在于，设置一个相对时间，在该非简单请求在服务器端通过检验的那一刻起，当流逝的时间的毫秒数不足Access-Control-Max-Age时，就不需要再进行预检，可以直接发送一次请求。

当然，简单请求时没有预检的，因此这条代码对简单请求没有意义。

目前代码如下：

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

到现在为止，可以对跨域ajax请求进行响应了，但是该域下的cookie不会被携带在请求头中。如果想要带着cookie到服务器，并且允许服务器对cookie进一步设置，还需要进行进一步的配置。

为了便于后续的检测，我们预先在http://127.0.0.1:3001这个域名下设置两个cookie。注意不要错误把cookie设置成中文（刚才我就设置成了中文，结果报错，半天没找到出错原因）

然后我们要做两步，第一步设置响应头Access-Control-Allow-Credentials为true，然后在客户端设置xhr对象的withCredentials属性为true。

客户端代码如下：

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

服务端如下：

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

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

相信看了本文案例你已经掌握了方法，更多精彩请关注php中文网其它相关文章！

推荐阅读：

在Vue2.0中http请求以及loading的展示

process和child_process使用详解

The above is the detailed content of How to use CORS of the Koa2 framework to complete cross-domain ajax requests. For more information, please follow other related articles on the PHP Chinese website!