Cette fois, je vais vous montrer comment utiliser le CORS du framework Koa2 pour compléter des requêtes ajax inter-domaines. Quelles sont les précautions pour utiliser le CORS du framework Koa2 pour compléter des requêtes ajax inter-domaines. demandes Ce qui suit est un cas pratique, jetons un coup d'oeil ensemble.
Il existe de nombreuses façons d'implémenter des requêtes ajax inter-domaines, dont l'une consiste à utiliser CORS, et la clé de cette méthode est de la configurer côté serveur.
Cet article explique uniquement la configuration la plus basique qui peut compléter une réponse ajax inter-domaines normale (je ne sais pas comment faire une configuration approfondie).
CORS divise les requêtes en requêtes simples et requêtes non simples. On peut simplement penser que les requêtes simples sont des requêtes get et post request sans en-têtes de requête supplémentaires, et s'il s'agit d'une requête de publication, le format de la demande ne peut pas être application/json (car je n'ai pas une compréhension approfondie de ce domaine. S'il y a une erreur, j'espère que quelqu'un pourra signaler l'erreur et suggérer des modifications). Le reste, les requêtes put et post, les requêtes avec Content-Type application/json et les requêtes avec des en-têtes de requête personnalisés sont des requêtes non simples.
La configuration d'une requête simple est très simple. Si vous avez seulement besoin de compléter la réponse pour atteindre l'objectif, il vous suffit de configurer Access-Control-Allow-Origin dans l'en-tête de réponse.
Si nous voulons accéder au nom de domaine http://127.0.0.1:3001 sous le nom de domaine http://localhost:3000. Vous pouvez effectuer la configuration suivante :
app.use(async (ctx, next) => {
ctx.set('Access-Control-Allow-Origin', 'http://localhost:3000');
await next();
});Utilisez ensuite ajax pour lancer une requête simple, telle qu'une demande de publication, et vous pourrez facilement obtenir la réponse correcte du serveur.
Le code expérimental est le suivant :
$.ajax({
type: 'post',
url: 'http://127.0.0.1:3001/async-post'
}).done(data => {
console.log(data);
})Code côté serveur :
router.post('/async-post',async ctx => {
ctx.body = {
code: "1",
msg: "succ"
}
});Ensuite, vous pouvez obtenir les informations de réponse correctes.
Si vous regardez les informations d'en-tête de la requête et de la réponse à ce moment-là, vous constaterez que l'en-tête de la requête a une origine supplémentaire (il existe également un référent pour l'adresse URL de la requête), et le l’en-tête de réponse a un Access-Control-Allow-Origin supplémentaire.
Vous pouvez désormais envoyer des requêtes simples, mais vous avez toujours besoin d'une autre configuration pour envoyer des requêtes non simples.
Lorsqu'une requête non simple est émise pour la première fois, deux requêtes seront en fait émises. La première est une requête de contrôle en amont. La méthode de requête de cette requête est OPTIONS. request Qu'elle réussisse ou non détermine si ce type de demande non simple peut recevoir une réponse réussie.
Afin de faire correspondre cette requête de type OPTIONS sur le serveur, vous devez créer un middleware pour correspondre et donner une réponse afin que cette pré-vérification puisse réussir.
app.use(async (ctx, next) => {
if (ctx.method === 'OPTIONS') {
ctx.body = '';
}
await next();
});De cette façon, la demande OPTIONS peut passer.
Si vous vérifiez l'en-tête de la demande de contrôle en amont, vous constaterez qu'il y a deux autres en-têtes de demande.
Access-Control-Request-Method: PUT Origin: http://localhost:3000
Négociez avec le serveur via ces deux informations d'en-tête pour voir si les conditions de réponse du serveur sont remplies.
C'est facile à comprendre. Puisque l'en-tête de requête contient deux informations supplémentaires, l'en-tête de réponse doit naturellement avoir deux informations correspondantes. Les deux informations sont les suivantes :
Access-Control-Allow-Origin: http://localhost:3000 Access-Control-Allow-Methods: PUT,DELETE,POST,GET
Access-Control-Allow-Origin: http://localhost:3000 Access-Control-Allow-Methods: PUT,DELETE,POST,GET
Origin: http://localhost:3000
$.ajax({
type: 'put',
url: 'http://127.0.0.1:3001/put'
}).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');
await next();
});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中文网其它相关文章！
推荐阅读：
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
Mot de passe par défaut du routeur
Comment remplacer uniformément les images d'arrière-plan ppt
La différence entre recv et recvfrom
Comment obtenir l'adresse de la barre d'adresse
Trois façons de terminer un fil de discussion en Java
Comment résoudre le problème du transfert lent du nom de domaine du serveur
Que signifie le HD du téléphone portable ?
Quels sont les types de données ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
