1. 前言
最近在本地开发环境测试公司系统时,遇到了跨域问题,导致无法登录获取用户权限。原本只要是本地浏览器存储了目标服务器的cookie 信息就可以发送跨域请求,但奇怪的是,已经通过开启 CORS 同源请求的方式获取到了 cookie,在本地开发环境启动的系统依然出现了跨域情况,检查发现请求根本没有自动携带 cookie。为什么开启了 CORS,还是会出现跨域的问题呢?
文章大纲
-
分析问题
-
为什么会有跨域问题
-
如何解决跨域问题
-
为什么开启 CORS,还会出现跨域
-
解决问题
-
浏览器关闭 Same-Site
-
使用第三方代理
2. 分析问题
2.1 为什么会有跨域问题
跨域本质上是 浏览器实现**同源策略(Same Origin Policy)**的一种安全手段。对于同源的定义,url 协议
(protocol)、端口
(port)、主机
(host 域名)完全相同称为同源站点。同源策略限制了两个不同源站点的资源访问,比如前端想通过 XMLHttpRequest 将站点数据发送给不同源站点,就会产生跨域问题。
比如 A 源为:http://store.company.com/dir/page.html
,下列与 B 源 的对比。引用自 MDN Definition of an origin
| URL | Outcome | Reason |
| :------------------------------------------------ | :---------- | :----------------------------------------------- |
| http://store.company.com/dir2/other.html
| Same origin | Only the path differs |
| http://store.company.com/dir/inner/another.html
| Same origin | Only the path differs |
| https://store.company.com/page.html
| Failure | Different protocol |
| http://store.company.com:81/dir/page.html
| Failure | Different port (http://
is port 80 by default) |
| http://news.company.com/dir/page.html
| Failure | Different host |
而本地前端服务 http://localhost:9096
与服务端 http://api.backend.com
是不同源的,存在跨域资源访问限制问题。
2.2 如何解决跨域问题
解决跨域问题,有很多种方式,比如使用 JSONP
、CORS
、Proxy
等方案。在公司的项目中,使用了 CORS 方案。
CORS 跨域资源共享是为了解决同源策略的网络层面限制而引入的,它是一种基于 HTTP 头的机制,该机制通过允许服务器标示除了它自己以外的其他 origin(域,协议和端口),这样会浏览器可以访问加载这些资源。
如何开启呢,比如一个登录 login
接口简单请求,浏览器发出的请求信息会添加 origin
字段,Origin
字段用来说明,本次请求来自哪个源(协议 + 域名 + 端口)。服务器根据这个值,决定是否同意这次请求。
GET /cors HTTP/1.1
+ Origin: http://api.backend.com
Host: localhost:9096
Accept-Language: zh-CN,zh
Connection: keep-alive
User-Agent: Mozilla/5.0...
...
如果Origin
指定的域名在许可范围内,服务器会设置响应头 Access-Control-Allow-Origin
,浏览器会检查这个字段,从而让 XMLHttpRequest
正常获得结果,否则,就会抛出错误。
+ Access-Control-Allow-Origin: http://localhost:9096
Set-cookie: token=xxxx; Path=xxx
同时,服务器会通过 Session-Cookie
机制维护用户的登录状态,从而使用 Set-Cookie
告诉浏览器中写入 Cookie
。
登录成功后,客户端再次发送一个 getUser
接口用于获取用户权限信息,要携带之前的 Cookie
发送给服务端。
由于 CORS 请求默认不发送 Cookie 和 HTTP 认证信息。所以要把 Cookie 发送到服务器,需要 ajax
请求中开发 withCredentials
属性 为 true
,并且服务端要指定 Access-Control-Allow-Credentials
字段:
+ Access-Control-Allow-Credentials: true
并且Access-Control-Allow-Origin
就不能设为星号,必须指定明确的、与请求网页一致的域名。这样,就可以实现携带 Cookie 正常访问不同源的服务端资源了。
2.3 为什么开启 CORS,还会出现跨域
通过查看浏览器的 Chrome Network 发现,登录成功后,getUser 接口发送的浏览器请求没有正常携带 Cookie 字段。关于 cookie 无法被携带问题,有不少排查的方向,
-
浏览器是可以禁用 Cookie 的
chrome://settings/cookies?search=cookie
-
浏览器的插件导致,可以考虑使用无痕模式测试
-
是否开启了某些工具模拟请求,网络设置问题
-
是否是 Cookie 的属性设置问题,比如 domain、path、失效时间等。
-
...
经过仔细排查后发现这是因为浏览器设置的 Cookie 的 Same-Site 属性问题,导致 Cookie 无法被正常携带。
Cookie
的 Same-Site
属性是为了防止(CSRF-Cross-Site-Request-Forgery)跨站请求伪造攻击
,CSRF 是指在受害者访问一个网站时,其 Cookie 还没有过期的情况下,攻击者伪造一个链接地址发送受害者并欺骗让其点击,从而获取用户信息。
Same-Site
名为同站,那它跟跨站、跨域有什么区别呢,理解它们的区别有利于我们更好的理解 Cookie
的 Same-Site
属性。
2.3.1 同站(Same-Site)、跨站(Cross-Site)与跨域(Cross-Origin)的区别
跨域
本质上是 浏览器实现**同源策略(Same Origin Policy)**的一种安全手段。对于同源的定义,url 协议(protocol)、端口(port)、主机(host 域名)完全相同称为同源站点。
同站与跨站
只要两个 URL 的eTLD+1
相同即是同站,否则为跨站,不需要考虑协议和端口。
eTLD: (effective top-level domain) 有效顶级域名,注册于 Mozilla 维护的公共后缀列表(Public Suffix List)中,如 .com
、.org
、.com
等
eTLD+1: 有效顶级域名 + 二级域名,如 taobao.com
,baidu.com
,sugarat.top
2.3.2 Cookie 的 Same-Site
大部分网站使用了 Cookie 来存储登录状态,保护 Cookie 不被三方站点利用尤为重要,我们可以合理设置 Cookie
的 Samesite
属性值防御 CSRF
攻击。
-
strict
:严格校验,严格校验站点是否为同源 -
lax
:较宽松校验,在跨站点的情况下,从第三方网站打开链接,get 方式提交表单都会携带 cookie,
但如果在第三方站点中使用了 post 方法,或者通过 img,iframe 等标签加载的 url,会禁止 cookie 发送
none
:不校验第三方站点是否为同源或同一站点,任何情况下都会发送 cookie
3. 解决问题
3.1 浏览器关闭 Cookie 的 Same-Site
我们可以通过手动关闭 Cookie 的 Same-Site,这样就正常携带 Cookie 给服务端了。在 Chrome 浏览器中可以输入 chrome://flags/
把 SameSite by default Cookie
和 Cookies without SameSite must be secure
禁用掉。
-
SameSite by default Cookie
禁用或开启 SameSite Cookie 的规则 -
Cookies without SameSite must be secure
:当没有设置SameSite
属性或者设为None
的时候,开启这个规则就要求跨站的前后端数据通信必须是 https 协议。
在 91 版本以前,是可以这样做的。仔细发现浏览器 Chrome 自动升级到了 91 版本,91 版本不再给手动关闭了。
如果想让后端设置响应头关闭,通过设置 Set-Cookie
时设置 Same-Site
属性为 none
,但是这种做法要 https 协议才支持,必须设置 Secure
属性。
Set-Cookie: widget_session=abc123; SameSite=None; Secure
既然不能手动设置了,还有其他的方案吗?
方案一:本地开发暂时不升级到 91 版本了。
方案二:通过反向代理解决这个问题。
接下来具体说说方案二。
3.2 使用第三方代理
在使用代理解决 Cookie 携带问题前,先要搞懂什么是正向代理和反向代理。
正向代理与反向代理的区别是他们提供的服务对象不同,
-
正向就是对服务获取方服务的,表现为在客户端的出口位置,主要解决客户端的问题(比如科学上外网)
-
反向就是对服务提供方服务的,表现为在服务端的网络入口位置,主要解决服务端的问题(负载均衡)
来自知乎某图 www.zhihu.com/question/24…
3.2.1 正向代理
举个例子,没有代理的情况下,日常 git clone 仓库常常 443 错误,这是 https 开放的默认端口。
git clone https://github.com/alexjoverm/typescript-library-starter.git ts-axios
Cloning into 'ts-axios'...
fatal: unable to access 'https://github.com/alexjoverm/typescript-library-starter.git/': LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to github.com:443
# 使用socks5协议
HTTP_PROXY="socks5://127.0.0.1:1086" HTTPS_PROXY="socks5://127.0.0.1:1086" git clone https://github.com/alexjoverm/typescript-library-starter.git ts-axios
# 使用http协议
HTTP_PROXY="http://127.0.0.1:1087" HTTPS_PROXY="http://127.0.0.1:1087" git clone https://github.com/alexjoverm/typescript-library-starter.git ts-axios
正向代理:客户端 --- 代理服务器 --- 目标服务器。这样就可以正常下载仓库了。
3.2.2 反向代理
除了使用反向代理作负载均衡外,还可以使用反向代理解决跨站携带 Cookie 的问题,核心思路就是在前端本地使用代理服务器,整个数据的传递方式是 目标服务器---代理服务器---浏览器
,而本地代理服务器与本地浏览器是属于同站,不存在跨站问题,而服务器与服务器之间传递数据没有同源策略的限制,并不会存在跨域行为,代理服务器与目标服务器之间能正常转发 Cookie, 浏览器就能正常携带 Cookie 给目标服务器了。
如果你是 Vue 项目的话,一般是通过 Vue-Cli
脚手架搭建,要使用实现代理服务,可以直接在 vue.config.js
文件对应 webpack
的 w配置增加 devServer.proxy
配置,值为要被代理的目标地址,
module.exports = {
devServer: {
port: 9000
proxy: 'http://backend.com:4000'
}
}
前端根据 devServer.port
修改资源请求的地址为对应的 localhost + port
的形式即可,也就是说前端直接请求代理服务器地址即可,http://localhost:9000
,这样前端发送请求,由于与代理服务器是同站,浏览器就会携带上 Cookie,Cookie 经过代理服务器进行转发给目标服务器,这样就可以正常维持登录状态了。
除了上面的方式外,你也可以使用 node 构建一个简单的代理服务器
const http = require("http");
const httpProxy = require("http-proxy"); // 通过 http-proxy 实现代理功能
const proxy = httpProxy.createProxyServer();
proxy.on("error", function(err, req, res) {
res.end();
});
const proxy_server = http.createServer(function(req, res) {
proxy.web(req, res, {
target: "http://backend.com:18080" // 目标服务器
});
});
proxy_server.listen(8080, function() { // 代理服务器监听的端口
console.log("proxy server is running");
});
如果在生产环境上,前端应用与后端应用不在同一个服务器上,还可以使用 nginx 进行代理转发。
-
把访问
http://代理服务器地址:9001/edu
的请求转发到http://目标服务器1:8080
-
把访问
http://代理服务器地址:9001/vod
的请求转发到http://目标服务器2:8081
server {
listen 9001; // 代理服务器端口
server_name xxx.xxx // 代理服务器域
;
location ~ /edu/ {
proxy_pass http://目标服务器域1:8080;
}
location ~ /vod/ {
proxy_pass http://目标服务器域2:8081;
}
}
4. 小结
对于 Cookie Same-Site 的处理,本质上还是解决跨域的问题,离不开业界的方案,比如 CORS、设置代理,还可以通过 token 认证方式绕过这种处理,前端拿到服务端的 token 保存到本地,每次请求时都写到请求头里,这也是一种方案。
参考资料
-
跨域资源共享 CORS 详解 阮一峰大佬,详细讲解了 CORS 机制对简单请求和非简单请求的两种不同处理,以及客户端和服务端的配置区别。