
1 caryqy 2024-07-11 11:16:30 +08:00 |
2 lemon1997 2024-07-11 11:16:53 +08:00 挺好的,有些后端跨域也整不明白 |
3 xiaoluxiaolu 2024-07-11 11:18:57 +08:00 ,干了好几年后端,一直听有这个问题,其实也不知道为啥 |
4 sofm 2024-07-11 11:19:23 +08:00 楼主说的有道理,跨域很好解决。 但有些人又不去研究下 |
5 FreshOldMan 2024-07-11 11:20:10 +08:00 |
6 InDom 2024-07-11 11:20:14 +08:00 看了开头,习惯性先看末尾是否引流,v50 之类的。 作为一个后端,很早之前就理解跨域的缘由,虽然一开始不太理解明明很简单的东西,身边为什么有人就是不理解,就算知道也讲不明白是怎么回事。 后来也释然了,不理解我也不想讲了,反正你知道这样不行就行了,我可不打算把 URI 与 URL 的区别也将清楚。 我也不想扩展太多,因为懂得早就懂得,剩下的你讲了也听不进去,听进去也理解不了。 |
7 qq135449773 2024-07-11 11:22:26 +08:00 能讲明白跨域该没工作还是没工作,世界就是这样的残酷~ |
8 yangxin0 2024-07-11 11:24:14 +08:00 需要的时候问一下 GPT 就好了。 |
9 shadowyue OP @qq135449773 没事,乐观点,懂得多总比懂的少更让人感觉充实。 |
10 ounxnpz 2024-07-11 11:26:13 +08:00 作为后端,我都直接: ``` Access-Control-Allow-Origin: * ``` |
11 SleepyRaven 2024-07-11 11:26:32 +08:00 /t/1056317 这个帖子确实给我看流汗了 |
12 villivateur 2024-07-11 11:27:12 +08:00 所以,如果有一个恶意浏览器,故意给某些网站开跨域后门,那用户/被跨域的站点就会被坑。 |
13 shadowyue OP @bluicezhen 开发环境可以,线上还是建议你是用白名单,安全点。 |
14 dumbass 2024-07-11 11:28:44 +08:00 「 我认为这是现在的前端脚手架提供的一个极其糟糕的功能。 它把跨域这个完全由后端处理的问题默默的在开发环境处理掉了,并且还附加了接口地址改写的各种功能 导致前后端都稀里糊涂的。跨域问题就应该在开发环境处理掉。 」 不认同,这就是脚手架要做的啊。 |
15 wangxiang 2024-07-11 11:29:01 +08:00 - 有跨域问题请求不通,帮忙放开一下。 - 你就不能搜一下 JS 怎么解决跨域,别什么都来麻烦后台 |
17 TimPeake 2024-07-11 11:30:27 +08:00 唉 认知差异太大。 做好自己就行,别为这些事情上头。 你要知道 工作 3 年的前端/后端,网络知识不通的人大把抓, nginx 基础配置都不懂的更是遍地都是。 告诉自己不要生气,你是来打工的。 |
18 dumbass 2024-07-11 11:30:50 +08:00 |
19 shadowyue OP @bojackhorseman 如果没有这个功能,前后端会早早的尝试在开发环境进行跨域处理。 正如我标题的第一句话,既然大家都是草台班子,问题还是早点暴露的好,不要留到线上环境去。 |
20 9c04C5dO01Sw5DNL 额。。。我认为楼主要是完全搞明白了,就不会说是 “跨域” 了,也不知道这个词最开始是谁给翻译的。 这个词严谨的说法应该叫 “跨源” , 源包含了:域、协议或端口 。"同源策略"中的 “源” 说的也是这个 |
21 magicZ 2024-07-11 11:31:56 +08:00 这个问题概念都忘了,我直接把 nginx 配置记到笔记了,遇到就粘上去 |
22 ruke 2024-07-11 11:33:56 +08:00 都用 jsonp 去吧 |
23 justdoit123 2024-07-11 11:34:18 +08:00 太正常了。 web 环境跟 server 环境经常混为一谈。狭义一点的 web 环境,应该是指浏览器环境。 但是 http server 不是只服务于浏览器。 经典的几个莫名其妙的问题以及神奇操作。 1. cookie 与 session 有什么区别?二者不是之间替代品,没什么好比较。 2. cookie 与 jwt token 有什么区别?二者不是之间替代品,没什么好比较。 3. 在浏览器环境,把 jwt token 塞 Authentication header 里。那请问你的 jwt token 不是需要让 js 访问吗?那不是等于会泄露在某处? 4. 把公开的 API 加上 CSRF 保护。这类 API ,一般会用服务于 sdk 、app 、server 2 server ,这种场景下防什么 CSRF 攻击。CSRF 攻击只在浏览器发生。server 可以分流,身份信息 放在 cookie 里的,是浏览器流量,需要 CSRF 保护,放在 Authentication header 里的,是一些非浏览器流量,不需要 CSRF 保护。 ... |
24 eWS2mq278TTzoj0O 2024-07-11 11:35:26 +08:00 @wangxiang 已经有画面了。。 |
25 shadowyue OP @ruke 还留在上个时代的开发确实会说这个技术方案,虽然也不是不行,只要公司的安全组允许所有接口都是 get 就行 |
26 iphantom 2024-07-11 11:35:59 +08:00 点个赞~ |
27 darksword21 PRO 我是后端,我是理解跨域,只是之前每次听到前端说代理之类的让我很懵,我印象里前端就是静态文件怎么本地还要启动 http server 了,后来抓着前端同时聊才逐渐了解 |
28 ReinerShir 2024-07-11 11:37:23 +08:00 居然被人贴了。。 你说的这些知识我都知道 解释一下那个帖子,那个问题是部署平台的问题(具体哪个鬼平台我就不说了),部署完后不生效一直使用的老缓存,导致我以为是 vite 在搞鬼,现在已经 OK 了,直接请求的后端接口 |
29 shadowyue OP @justdoit123 你这个内容解释起来恐怕吵架更多,害怕.jpg |
30 wangritian 2024-07-11 11:39:02 +08:00 我起后端项目,跨域头是必备的中间件,origin 不能设置*,要根据请求头的 Host 来 |
31 shadowyue OP @ReinerShir 没事哥,我草包一个,只是借用你的贴聊聊而已。 |
32 tyrone2333 2024-07-11 11:39:28 +08:00 @wangxiang 我们公司有个网关,各种过滤和阉割,跨域都好几个地方配置,连后端老大都不知道哪里配 |
33 TimPeake 2024-07-11 11:39:39 +08:00 @ReinerShir 生产环境跟 vite 没有一毛钱关系 ,“部署完后不生效一直使用的老缓存,导致我以为是 vite 在搞鬼” 这个就是你自己认知的问题了。 |
34 jevirs 2024-07-11 11:39:53 +08:00 做了些前端面试,大家都能把同源策略说清楚,也能背出 jsonp 、proxy 等八股文方案,真问到 cors 相关的头是哪几个,全歇菜 |
35 herewego 2024-07-11 11:40:12 +08:00 我是全栈,我啥都知道[狗头] |
36 WonderCc 2024-07-11 11:40:16 +08:00 以前实习面试的时候有问过,说到要咋做,我还背过 nginx 什么的,现在完全忘记 |
37 xiaowunai 2024-07-11 11:40:24 +08:00 世界本来就这样 能用就行 |
38 4Et5ShxMIq58n6Lr 2024-07-11 11:40:41 +08:00 这个其实看看 MDN 就知道了,上面基本上都说了,关于跨域的相关的只是,例如为啥发 option 请求 |
39 shadowyue OP @jevirs 会背和真的会用还是有区别。 比如前端资源的缓存策略怎么做比较好,我面试也经常问,能用实践回答让我满意的就少多了。 |
40 shadowyue OP @laobobo 太对了哥,mdn 上面很多答案都是现成的。 害怕的是我不知道面试过多少前端,都不知道有 mdn 这个东西,汗流浃背了 |
41 Xrall 2024-07-11 11:42:59 +08:00 后面的都能理解,第一点的确是不知道的。 之前就有时候会出现前端请求跨域,然后就会让后端处理一下跨域。 但是奇怪的就是游览器报跨域后端压根没有收到任何请求。 那么 OP 说的第一点就让我稍微想得通一点了,肯定是出现了 node 的服务出现了异常导致没法正确转发。 回想一下也是每次遇见这种情况往往是本地重启一下服务就好了。 想想以前全都是 ajax 一把嗦,后端配置好了还真没遇见过前面说到的这种问题。 |
42 lisongeee 2024-07-11 11:43:49 +08:00 你这有点东西都没说清楚,不严谨,比如你说的《为啥我见过浏览器发 option 请求?》 这叫预检请求,不是每次都发,只有当发起复杂请求时才会发起,使用 fetch 、xhr 发起 无复杂参数(浏览器认为无副作用)的 get 和 post 是 *没有预检请求* 的,而且服务器能收到并且正确处理 但是也需要返回允许 cors 的 headers ,否则浏览器不会把 response 传递给 js |
44 byte10 2024-07-11 11:44:49 +08:00 (⊙o⊙)…有一个东西 我觉得应该可以讲一下,为啥会有跨域问题。。。不限制 跨域会有什么问题,小程序为啥没有跨域问题。 |
45 nthin0 2024-07-11 11:47:37 +08:00 via iPhone 感谢讲解,学习了 |
46 ylh1024 2024-07-11 11:49:26 +08:00 chrome --user-data-dir="C:/Chrome dev session" --disable-web-security --disable-site-isolation-trials |
47 silencil 2024-07-11 11:50:05 +08:00 很好!我个人觉得我是理解跨域的,也知道是浏览器的策略。但是一旦被问的话,估计也是说不上来。另外,我就是这种三四年的菜鸡,也不会配置 Nginx 。 |
48 Xrall 2024-07-11 11:50:27 +08:00 @shadowyue #43 这个是知道的游览器做了拦截。 只不过还是有一点点疑惑,那就是我描述的这种情况的话。 原因是游览器发送了真正的请求地址从而被游览器认定跨域拦截, 还是说像描述中一样是因为一些问题导致 node 启动的服务没有正确转发呢? |
49 yuezhiyuan 2024-07-11 11:50:30 +08:00 但是在浏览器环境下,为了安全,浏览器只允许 js 访问固定的几个响应头。 ---- 如何理解这句话,例如接口返回了不允许的响应头,浏览器报跨域错误吗 |
50 GloryIsMine 2024-07-11 11:52:24 +08:00 这种问题在配置对象存储服务的时候也会遇到吧 不算小众问题吧 |
51 yuezhiyuan 2024-07-11 11:52:40 +08:00 跨域比想象中要复杂许多,例如 Access-Control-Allow-Origin: * 等于*时另外个跨域 cookie 的参数就不能等于 true 另外受 cdn 、nginx 的影响,响应头会被不小心更改到,导致产生跨域 |
52 zliea 2024-07-11 11:56:52 +08:00 via iPhone 不过一个项目开发的时候,如果项目组前后台沟通流畅的话,提前规划接口与前台页面的路径。 比如 {BASEURL}/yewuA/h5/是前台部署路径,{BASEURL}/yewuA/api/是后台部署路径。 前端可以控制 baseurl 放在不同环境的环境变量中打包。 前端脚手架来解决跨域问题是可以的,总不能现在还是让前端启动配置一个和测试生产环境一样的 nginx 来调试吧。 现在前端由于是编译的,没法做到使用类似../../这种相对路径请求接口,但前端接口请求一定不能是完整地址待域名端口(类似 http://域名:端口/)这种,一定要是直接到根这种。 |
53 azhangbing 2024-07-11 11:57:05 +08:00 因为跨域限制是古早时候 浏览器的同源策略 那时候一般都放在同个域名,端口下的 很早很早了 |
54 yusf 2024-07-11 11:58:50 +0:00 跨域是浏览器行为 |
55 xiaochena 2024-07-11 11:59:45 +08:00 @bluicezhen Access-Control-Allow-Origin: * 就不能带 cookie 了哦 |
56 0IuL7w7X5K2HJxZf 2024-07-11 12:02:30 +08:00 跨域的问题不只是原理,你以为理解了,MDN 那个文档看过无数遍了,但是每次和前端对接都会出现新的问题,xhr ,fetch ,axios ,不同的库对 cors 的使用方法和处理方式不同,烦人的很,而且现在的跨域限制的更多了,以前能行的办法突然发现某些情况下又不行了。 |
57 iOCZS 2024-07-11 12:04:43 +08:00 人们制定了很多规则,但是又不善于记忆规则。 |
58 encro 2024-07-11 12:04:52 +08:00 讲点核心的: 首先,你得理解为什么浏览器要限制跨域: 1 ,比如我公司的静态 js 和图片,被某大流量网站直接引用了,我流量不直接被刷爆? 2 ,某域名直接 iframe 之类嵌套,或者引用我的资料,打着李逵额名号,其实是李鬼。 所以,浏览器限制了跨域请求。 问:那么,我们开发时,想要访问线上接口怎么办? 答:我们可以用 vite 之类 nodejs 的代理功能,通过代理访问线上接口,代理一词的意思是我们访问本地的接口,代理服务器通过本地程序(非浏览器)转发到线上接口。 问:如果我们确实有线上项目的跨域请求的需求怎么办? 答:我们可以在服务器设置 Access-Control-Allow-Origin ,将我们自己人加入白名单。 跨域,就是这么简单! |
60 bertonzh 2024-07-11 12:07:06 +08:00 「我认为这是现在的前端脚手架提供的一个极其糟糕的功能」 你这个观点不对。 本地开发服务器会提供接口代理,它的一个重要的背景是: 世界上绝大多数网页服务,网页域名跟接口域名是一样的,也就是线上一般不会存在跨域问题。 开发工具做这个代理逻辑,仅仅是为了跟线上保持一致而已。 确实存在接口域名跟网页域名不一样的时候,但是这不应该是常态。因为即使处理了跨域的问题,还有三方 cookie 的问题等着你。 |
61 wojiugaiming 2024-07-11 12:08:52 +08:00 via Android 前端的事情前端完成,别什么都麻烦后端 |
62 AV1 2024-07-11 12:11:01 +08:00 @shadowyue 跨域请求,后端是有日志的。 而且如果是 GET 请求,在后端看来,甚至是一次成功的请求,它感知不到自己返回的结果被浏览器拦截了。 我们看到的“Access to fetch at 'xxxx' from origin 'xxxx' has been blocked by CORS policy”异常,是发生在接受返回值的阶段,而不是发请求的阶段: JS>浏览器>服务器>浏览器 >JS |
63 shadowyue OP @bertonzh 原来如此,感谢你的回复。因为目前我这边的项目页面域名和服务端域名都是不相同的。 你这个说法也很有道理。 |
65 JKKK 2024-07-11 12:16:17 +08:00 跨域本质上是个浏览器的安全策略,配合 HTTP 头信息安全的使用其他域名的资源 |
66 shadowyue OP |
67 nevermoreluo 2024-07-11 12:18:03 +08:00
|