CORS相关问题


难度 中等

前言

  • CORS (Cross-Origin Resource Sharing) 是每个网页开发者早晚都会遇到的问题。当你阅读这篇文章时,你很有可能正在处理一个CORS错误。本文,我将告诉你CORS是什么,以及如何处理CORS错误。

  • 这就是你正在处理的问题吧!

  • 我们正在试着从本机的1234端口请求一个位于本机的3000端口的一个url下的资源,这个请求被CORS阻止了,因为两个地址的端口是不同的。
  • CORS默认阻止所有不同“来源”之间的任何形式的请求。这能阻止人们从不在他们控制范围内的服务器那里获取数据。想象一下,你并不希望随便哪个人,只要拿着你的cookie,假装是你一样,向你的知乎账号或者银行账户发起请求(这些cookie中可能含有你的关键信息)。
  • CORS不关心来自相同“来源”的请求。如果你从本机3000端口的根目录请求其中的一个子目录的资源,CORS不会起作用,你也不会遇到阻碍。
  • 相同的“来源”可以理解为相同的scheme并且相同的host并且相同的port。

如何解决CORS?

  • 如果你想从你的服务器向你的客户端发起请求,并且他们位于不同的“源”,那么你需要 ↓

  • 让你的服务器向客户端在每次请求的响应报文中加入 Access-Control-Allow-Origin 的字段,取值为服务器允许的客户端访问的源。

  • 注意:如果你不打算对客户端的来源做任何限制,你可以将这个字段设置为*。

  • 比如,我们正在从本机1234端口向本机3000端口发送请求,那么我们就要在从3000向1234返回的响应报文中加入 Access-Control-Allow-Origin 的字段,取值设置为xxx:1234,即服务器允许的请求来源地址。

  • 如何让服务器返回这个字段呢?这取决于你使用的编程语言。如果你使用的是Node.js,可以使用cors库。如果是其它语言,也可以找到合适的处理手段。


CORS 预告

  • 如果你正在跨域请求一个PUT请求,等更为复杂的请求。那么仅仅按照上文所述进行操作是不够的。当跨域请求为简单的请求,如GET和POST,那么不会进行CORS预告。
  • 浏览器会在发送请求报文之前发送一个预告报文,询问服务器是否允许PUT请求。这个预告的请求报文会包括 Access-Control-Request-Method 和 Access-Control-Request-Headers 的字段,包含了客户端将要在正式的请求中使用的方法和请求头的值。
  • 之后,服务器会在响应报文中告诉浏览器,这些方法和请求头是否有效。这些信息会放在 Access-Control-Request-Headers 字段和Access-Control-Allow-Headers 字段中。如果浏览器发现这些字段完全匹配,那么正式请求就得以实现。
  • 如果使用node.js的cors库,实现这个操作的方式会很简单:
const express = require('express')
const app = express()
const cors = require('cors')

app.use(cors({
  origin: 'http://localhost:1234',
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type']
}))

// Server code 

app.listen(3000)
  • 这样服务器就会响应报文中添加刚才说的那些字段。值得一提的是,你并不需要手动设置allowedHeaders字段,因为它的默认值和客户端发来的那个字段中的值相同。

CORS 设置cookie

  • 默认情况下,CORS不会允许设置cookie。如果你希望能够使用,需要做两件事: ↓
  1. 浏览器告知服务器,我需要设置cookie。
  2. 服务器将 Access-Control-Allow-Credentials设置为true,允许使用cookie。
  • js实现如下:

  • 客户端:

  • javascript fetch(url, { credentials: 'include' })

  • 服务器端(使用cors库实现):

const express = require('express')
const app = express()
const cors = require('cors')

app.use(cors({
  origin: 'http://localhost:1234',
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type'],
  credentials: true
}))

// Server code 

app.listen(3000)

总结

  • CORS默认阻止不同来源的任何形式的请求。这样一来,服务器可以只对其信任的请求方提供数据和服务,提高安全性。为了解决CORS报错的问题,只要让服务器信任自己使用的客户端就可以了,这需要让服务器在响应报文中为Access-Control-Allow-Origin字段添加相应的值。如果为了调试方便,可以设置为*****,对来源不做限制。

文章作者: growdu
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 growdu !
  目录
分类导航
随笔3 AI29 计算机基础13 算法1 博客搭建7 ChatGPT2 集群63 计算机通信1 数据库59 数据库深入93 数据库93 Docker11 DPDK26 编辑工具4 Elasticsearch4 FAQ1 Go Web1 hometown2 编程语言16 人生11 网络9 Linux38 OPC1 openGauss4 页面12 PostgreSQL54 程序员自我修养1 协议11 stock1 存储5 成长之路1 工具20 视频作品1 VPP18 Vue13 Web1 代码示例11 BenchmarkSQL1 PostgreSQL 源码修炼之路14
最热文章
1
PostgreSQL 逻辑复制全链路:以一个真实事务为例,从 `INSERT` 到 `apply` 的源码级旅程
数据库🔥 2162
2
PostgreSQL 逻辑复制 Stream 执行逻辑源码级拆解:从 reorderbuffer 触发到订阅端落盘回放
数据库🔥 1765
3
PostgreSQL 行锁机制源码级深度拆解:4 种锁模式 + xmax + MultiXact 的完整链路
数据库🔥 1656
4
PostgreSQL reorderbuffer.c 函数级源码全集:5615 行 / 95 个函数的逐函数解析
数据库深入🔥 1650
5
PostgreSQL 目录快照源码级深度拆解:系统表读取的 MVCC 真相与失效机制
数据库🔥 1604
6
13 逻辑复制深入
数据库深入🔥 1570
7
0 Postgresql存储、索引及系统优化、主备切换
PostgreSQL🔥 1495
8
PostgreSQL 读一行数据源码级深度拆解:MVCC 在每个环节的落点
数据库🔥 1464
9
PostgreSQL WAL 记录类型完全指南:21 个 RMGR × 80+ 种记录的源码级拆解
数据库🔥 1431
10
一文读懂openguass dcf网络模块
集群🔥 1420
11
PostgreSQL 元数据存储机制:从磁盘文件到内存缓存,`pg_class` 撑起的整个系统表体系
数据库🔥 1411
12
openGauss 并行解码设计原理深度拆解:reader + 多 worker + CSN 三层架构的源码级剖析
数据库深入🔥 1344
13
逻辑复制源码分析
数据库深入🔥 1327
14
PostgreSQL 逻辑复制:catalog 改动、可见性判定与 xmin/xmax 推进全景
数据库深入🔥 1317
15
自托管服务全家桶:从原文方案到可复制实操手册
人生🔥 1278
16
PostgreSQL CREATE_REPLICATION_SLOT 端到端源码分析:从 SQL 到 snapbuild 状态机的完整链路(每个函数每个参数)
数据库深入🔥 1277
17
PostgreSQL syscache 模块源码深度拆解:CatCache 数据结构、LRU 哈希表、cache invalidation 全链路
数据库深入🔥 1216
18
PostgreSQL 18 内核数据结构全景:RangeVar 与 20+ 个核心数据结构源码级拆解
数据库🔥 1158
19
PostgreSQL 逻辑复制里 `RUNNING_XACTS` 写入机制与快照 `xmin / xmax / xip` 的演化:源码级深度拆解
数据库🔥 1119
20
PostgreSQL 分区表:从一行 `PARTITION BY` 到路由热路径的全链路拆解
数据库🔥 1094