106
poorcai 167 天前
确实想问下,既然跨域是浏览器决定的,那后端设置允许跨域是干啥的?(´・_・`)?
|
107
shadowyue OP |
108
NessajCN 167 天前
@shadowyue 你看,从你纠结是 fetch api 还是 XMLHttpRequest 就说明你不光没搞懂 cors request 坑在哪里也没看明白我在说啥
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials 看这一段 「 In addition, this flag is also used to indicate when cookies are to be ignored in the response. The default is false. XMLHttpRequest responses from a different domain cannot set cookie values for their own domain unless withCredentials is set to true before making the request. The third-party cookies obtained by setting withCredentials to true will still honor same-origin policy and hence can not be accessed by the requesting script through document.cookie or from response headers.」 跟我上一个 fetch API 里的说明是不是一模一样?这跟你用哪个函数请求毫无关系 |
111
abersheeran 167 天前 1
为了解决 CORS 的问题……我做的框架里,allow_cors 默认就是全开(能带上 cookies 用的那种),不懂这种东西的人太多了,框架提供太多安全性保护,反而这帮小白觉得难用(比如 Django CSRF )
|
112
mizuhokaga 167 天前 1
学习了,作为后端有时候写前端对跨域一直模模糊糊的
看完算是打通了,非常感谢 op 分享 |
113
LiuJiang 167 天前 1
真的是这样,我对接过很多后端,TM 都不知道跨域。。。
|
114
NerbraskaGuy 167 天前 1
不懂跨域的后端挺多的,经常有后端把 get 请求粘浏览器地址栏里问我明明可以正常请求啊为啥是跨域问题....
|
116
Nosub 167 天前
@shadowyue 我的文章是针对前端开发人员调试用的,并不是针对普通客户,钉钉加入白名单是一种方式,但是:并不是所有环境都是可配置的,我文章也说了,如果你后端服务已经上线,而且已经设置了跨域,你前端要调试呢,当然你又说可以加入白名单,难道又要后端重新打包吗?
|
117
shadowyue OP @Nosub #116
这就是跨域安全策略的意义所在。如果后端的配置你没有权利更改或者不能配合你修改, 最大的可能是,后端服务不属于你或者不是给你提供服务的。 其它有什么特殊情况导致后端无法协助配合处理跨域你可以讲讲。 |
118
asuraa 167 天前
这有啥说不清的 跨域就是浏览器的一个限制本质上是为了安全防止跨站脚本攻击的
|
119
Gotchaaa 167 天前 1
上面讨论了很多,讲个冷知识,小程序不会跨域(应该吧
|
120
gowinder 167 天前 1
分享得很好. 下次多来点.
|
121
NessajCN 167 天前
@shadowyue 行了行了看不懂直说就好了。新手没踩过 credential request 的 same-origin 坑看不懂很正常。
但你没真正排查过跨域大坑却来教别人啥是跨域就有点幽默了。 还是要多写写代码 |
122
sayitagain 167 天前
@bluicezhen #10 我也这样,但是上次遇到前端发起的预检请求 option 过不了这一段,还得额外加 Access-Control-Allow-Methods: GET, POST, PUT,DELETE,OPTIONS,PATCH 才能过,不知道为什么
|
123
kxg3030 167 天前
同理 能把编码问题解释清楚的人也没几个 能把二进制与文本区分开的人就更少了
|
125
mercury233 167 天前
代理解决不了跨域,用量一大就会被对方当爬虫封掉
|
126
kxg3030 167 天前
@bluicezhen 这样大部分情况也已处理 但是遇到前端要提交 cookie 这样设置是不行的哦 好了 你的知识又增加了
|
127
9c04C5dO01Sw5DNL 167 天前 3
|
128
lolizeppelin 167 天前 1
写后端的不明白才是水平不到位....
但凡读过框架跨域处理的部分然后脑子想一想,随便再翻点资料就搞明白了 |
129
Nosub 167 天前
@ooolooo 哈哈哈,字面意思的确有点歧义,其实我想说的是 [前端开发人员] 简写成了 [前端] ,这里是指客户端,我回复特别注明了,我觉得你没认真看就开喷,是不是有点过了。
|
130
mooyo 167 天前 1
哈哈哈我跟你说我还见过后端认为服务器证书是申请了自动和域名绑定的,不需要自己设置的。
|
131
9c04C5dO01Sw5DNL 167 天前
@ooolooo 复议
|
133
hellodigua 167 天前 1
@Nosub 小白看了你那个博文更迷糊,还是别误导人了
|
135
1183460943 167 天前 1
我也特别看中跨域这块,基本每次面试必问,感觉一个成熟的开发者不可能不懂这个,但实际上还是很多人整不明白
|
136
caqiko 167 天前 1
@poorcai #106 如果后端不允许跨域,那么由于浏览器的安全策略限制,https://example.com/index.html 页面里面的 js 不能通过 http 请求拿到接口 https://api.example.com/v1/get_users 的数据。但是这种应用场景又是客观存在的。
|
139
7gugu 167 天前 1
每次 CSP Error 我都要去提醒后台加跨域配置😅
|
140
bugfan 167 天前 1
在浏览器中会发生的现象:
浏览器会阻止给和页面地址不同的域名发请求。 这跟语言无关,这就是一个在浏览器环境下的安全策略。 op 提到的这一段不太准确。 应该是浏览器会阻止 js 发起到的不同域之后的响应,绝大多熟请求是已经发出去了,是浏览器把响应拦截了(有一些参数可以让 js 请求发出去之前就拦截,但是大部分情况都是前者)。js 发请求包括 axios ,ajax (底层都是用 XMLHTTPRequest ),还有 fetch 这种的等等。。。 另外,html 标签发起的跨域请求是可以直接出去的。 |
142
SSang 167 天前
让用户 `alias google-chrome='google-chrome --disable-web-security'` 从根本上解决跨域问题 😁😁
(我乱说的,别这么玩) |
143
Xinu 167 天前
|
144
nexo 167 天前 1
非 xhr 的 get 不会跨域
|
145
fresco 167 天前 1
确实,非常多的人理解不了跨域,我服了
|
146
haoswil 167 天前 1
在补一个,我们这边写前端的,vue 配置 publicPath 相对路径和绝对路径都不知道,我是 devops + SRE, 每次前端上线一个个这个 404 ,那个 404 , 简直智障
|
148
guguji5 167 天前
|
151
cenbiq 167 天前 1
跨域问题的根本是由服务器输出 html 也就是开放的动态客户端代码导致的,所以浏览器必须配合服务器做同源策略来限制跨域以阻止跨站攻击等问题,在先天前后端分离的静态客户端 app 上就不存在这个问题,而这部分开发者到了浏览器的开发环境中就会发现存在“奇怪”的跨域问题。
|
152
salmon5 167 天前 1
很多前端仔“缓存”更说不清楚。
|
154
xiaoxiyiha 167 天前 1
追根溯源,是为了解决浏览器的“同源策略”
|
155
ukpkmk 167 天前 1
学习了
|
156
brader 167 天前 1
楼主,有一点我和你的理解恰恰相反,我认为能真正理解和吃透跨域原理的人,正是后端莫属,因为要实现一个完整的跨域功能,其交互行为几乎都是后端完成的,前端只需做基本配合即可。
我说的是真正自己去实现过跨域组建的后端,那种只调过跨域包或者调调 NGINX 的不算。 我描述几点跨域实现细节中,容易忽略或者易犯常识性错误的点(仅部分,不代表全部实现细节): 1 、对预检请求 OPTIONS 的处理,应在你的接口代码之前就进行拦截处理并响应(可以简单理解为做在前置中间件)。 2 、不是所有 OPTIONS 请求方法都是“预检请求”,浏览器还应同时通过 Access-Control-Request-Method 请求头明确告知实际请求中使用的方法,未提供则服务端不认为是预检请求,不应做对应处理。 3 、Access-Control-Allow-Origin: *,他不是万能的,仅在不需携带 Credentials 的情况下可以这么设置;如需携带 Credentials ,必须指定一个单一的域名。 从以上可以看出,想自行实现一个标准的跨域组件,需在浏览器的跨域标准基础上,结合自身项目的实际情况,来合理的设置各响应头,而不是一股脑的使用 Access-Control-Allow-Origin: * 。 如果一名后端不清楚浏览器的跨域标准,请问如何实现这样的跨域组件呢?所以我说后端最了解跨域就这个原因了。 |
158
monologue520 167 天前
@jevirs 我一般说 ACA 家族(手动滑稽)~
|
159
zackzergzeng 167 天前
@xiaowunai 你不可能让每个用户都手动禁止吧,这才是跨域真正的难点🤪
|
160
xiaowunai 167 天前
@zackzergzeng
我不管,我就要,你自己想办法(狗头) |
161
monologue520 167 天前
@Jinnrry 这么离谱啊,果真是草台班子...
|
162
Canight 167 天前 1
我超,纯血技术帖
|
163
tywtyw2002 167 天前 via iPhone 1
看这帖子 想到了,之前那个帖子。
jwt 究竟是什么 哈哈哈 |
165
shenjinpeng 167 天前 1
待过几个公司, 身边人都知道啊, 前后端,测试 , 这种常见问题正常写接口的人都了解吧 哪有这么多草台班子
|
166
otakustay 167 天前 1
楼主这堆还没涉及到 cache ,cors+preflight+cache 混一起才是一场精彩大戏
|
167
sofm 167 天前 1
跨域很好解决的。 思路也很清晰,咋就这么多人不学习,不思考呢
|
168
abelmakihara 167 天前 1
纯前端不太可能不懂这个
不管是面试还是 devserver 多少会知道是干嘛的 大部分都是后端被迫兼职的 一看那个帖子果然又是.. |
169
yoyolichen 167 天前
一个贴子被挂了两次 有点好笑 doge
|
170
baolongqishi 167 天前
礼貌提问,我一般写 RPC 的,不写 web ,这个不懂应该正常吧( 2.5 年)
|
171
WJYuan 167 天前
@QlanQ #71 canvas 对图片有跨域限制的 https://developer.mozilla.org/zh-CN/docs/Web/HTML/CORS_enabled_image
|
172
lambdaq 167 天前
谁能讲明白 authority 和 origin 和 domain 的区别?
|
174
me1onsoda 167 天前
问题来了,为什么浏览器非要加上跨域限制,大家想方设法突破这个限制,理由也合情合理。这个限制的意义是什么
|
176
9c04C5dO01Sw5DNL 167 天前
@brader 不同意哈,只能说需要后端对跨源 "协议" 比较清楚,也就是 "what"和 "how",但是涉及到 "why" 的地方,我认为前端需要比后端更清楚。
|
179
gz65555 167 天前
『我认为这是现在的前端脚手架提供的一个极其糟糕的功能』这点不同意。
很多时候前端开发环境是本地,请求接口是跨域,但是生产部署后就是同域名访问接口了。 |
180
billbob 167 天前
看到在要在服务端处理跨域这种人,不是坏,就是菜.
前端开发你可以,自己代理,比如 vue,angular,js 都可以处理跨域,比如: 我本地开发调用正式环境 API 测试,这时候你难道跑去让后端给你把线上服务器改吗? 还有就是调第三方的 API 都需要做代理. |
181
brader 167 天前
|
182
shadowyue OP @billbob #180
你自己也说了开发环境。你要知道开发环境下前端对跨域处理的功能是无法应用到线上的。 生产环境你永远需要在服务端处理这个问题。 另外调用三方 API 也并不非要做代理。你使用云服务上传文件的接口,难道还需要让服务端转发一次文件上传流量? 你这个回复也很经典,非常感谢。 |
183
daliusu 167 天前
@lemon1997 不是有些,我上班到现在,除了一些全栈和早期能力特别强的,后面在中厂碰到的后端能了解跨域并且解决的,基本都是会运维技术的,纯后端个个懵逼,能知道跨域是个后端问题的就算不错了,有些好几年经验的后端碰到跨域就让去找前端解决...
|
184
cirzear 167 天前 1
学到了,感谢分享
|
185
osdnfpn 167 天前 1
🐮🍺 大佬讲的很细致,感谢分享!
|
186
fank99 167 天前
@bluicezhen Access-Control-Allow-Origin: *的问题是,浏览器因为安全策略,不能设置为*的时候,不能带 cookie
|
187
tangping 167 天前
@giiiiiithub 和修仙一样的级别 哈哈
|
188
MMDeJeVS3GtMVLeu 167 天前 1
我作为一个前端要说下:
1 、很多项目最终部署的时候是在一个域名下,自然就不存在跨域问题; 2 、很多后台不愿意(不会?)帮前端改 CORS ,前端为了调试,nodejs http 中间层很有必要,而且这个中间层不仅仅能做转发,劫持、mock 数据可以,所以它并不是一个糟糕的功能; 3 、我见过有企业做安全策略,Access-Control-Allow-Origin 不允许设置为*,只允许 GET 、POST 4 、存在即合理 |
189
zed1018 167 天前 1
顺带补充一下,有没有 OPTION 请求取决于是不是简单请求。没记错的话大概是用 form 表单,或者 xmlrequest 发起的 urlencode/form 的 GET/POST 请求,并且头信息里没有一些奇奇怪怪的头的算是简单请求,这种请求会直接发起不会通过 OPTION 做 preflight 。
非简单请求则会用 OPTION 做 preflight ,preflight 做了以后各种 CORS 头都正确符合请求的需要才会发起正式请求,并且正是请求中也要包含符合需要的 CORS 头。 |
190
loy6491 167 天前 1
我还以为有何高论,这些不是草台班子也应该懂的东西吗
|
191
fengyedzf 167 天前 1
|
192
Torpedo 167 天前 1
我一直拿这个来测试后端水平。
倒不是说看后端了不了解跨域,而是和对应后端沟通跨域问题,并做了简单解释,但是他还不能理解的,肯定是菜逼。 |
193
onice 167 天前 1
我是开发转安全,,学 web 安全第一课就是浏览器的安全措施之一,同源策略。正因为浏览器的同源策略,才会出现跨域的问题。
|
194
zsh2517 167 天前
@raviscioniemeche #123 前段时间做一个东西因为 emoji 表现问题改了好几次实现。然后最近闲下来,深入了解了一下 unicode 、emoji 与 UTF-X ,发现这玩意是个大坑。
而且更坑的一点是,很多平台特性实现不完全,以至于本来我想在笔记里举个例子,结果举出来的展现不出来😂 |
196
zsh2517 167 天前 2
@me1onsoda #174 @brader #181
防止资源注入主要是 CSP (内容安全策略)吧。写插件或者 user script 的应该遇到过。简单说是网站可以声明自己页面内允许的外部资源域名,不在域名内的会上报或者拒绝加载。 至于跨域的安全体现在哪,这个还真没仔细考虑过。刚才找 GPT 问了一下,沿用 #181 的例子,前端 a.com ,后端 b.com ,恶意网站 xx.com 。拦截的是从外部前端发到自己后端的情况 异常情况:假如没有 CORS 策略,且 b.com 的 cookie 设置了 samesite: None 。那么在 xx.com 就可以构造一个 fetch('https://b.com/someapi', {credentials: 'include'}),进而请求到 b.com 的数据。 而如果有 CORS 策略,在 options 预检请求时,b.com 的后端检测到非同源可以返回拒绝;或者返回固定的同源策略,比如 Access-Control-Allow-Origin: https://a.com ,浏览器也会拒绝 xx.com 的请求。 如果 a.com 请求 b.com 的话,因为 b.com 的 CORS 头说明了允许 a.com 、使用 XXX, YYY 方式请求,允许的 headers 是哪些……,如果 a.com 按照规则来,浏览器就不会拦截。 --- 另一种情况,假如 a.com 被恶意注入了发往 xx.com 的资源。这个时候 a.com 请求 xx.com 是靠 xx.com 的 CORS 判定的,拦不住。用到的应该是 CSP 。例如 Content-Security-Policy: connect-src 'self' https://b.com; |
197
watzds 167 天前
有些连 json 也整不明白
|
198
Bakyura 167 天前 1
看懂了,谢谢 op
|
199
leokun 167 天前 1
这个问题为什么会有这么多的讨论...
|
200
andytao 167 天前 1
你这属于不按套路出牌,没法提前预习准备答案呀。
|