这是一个创建于 454 天前的主题，其中的信息可能已经有所发展或是发生改变。
一个关于前端怎么看请求和请求跨域的文章 https://juejin.cn/post/7122473590238216229
 | 1 codehz 2024-07-12 11:30:26 +08:00  2 硬生生的把看文档就能解决的事情，转变成实验科学。。。 |
 | 2 victimsss 2024-07-12 11:34:28 +08:00 天天讨论 https 前端加密和跨域的问题 |
 | 3 weixind 2024-07-12 11:35:28 +08:00 1 事情本质也就同源策略几句话的事情。就是一些二把刀天天发文章污染知识网络。 |
 | 5 tool2dx 2024-07-12 11:37:57 +08:00 @codehz 一般跨域遇到的问题，都是调用别人网站的资源服务，这种情况自己解决不了。比如说我想下载一个 github.com/user/master/code.zip, github 就是不允许跨域，你也没办法。 这些在客户端里完全不存在的问题，放到浏览器里就举步为艰。 |
 | 6 wysnxzm 2024-07-12 11:39:56 +08:00 135 跨域 246 粘包 |
 | 7 shadowyue 2024-07-12 11:43:14 +08:00 虽然我知道你是给自己文章引流，但是写的真是又长又表述不清晰。。。还不如我发的那个帖子 拜托了哥，前端被嘲讽就是因为你这样 |
 | 8 gerefoxing 2024-07-12 11:48:11 +08:00 想起以前写 jsp 页面那个时候遇到跨域问题，调用的服务端非自己公司的，那时候还用过 jsonp 和 flash |
 | 9 AV1 2024-07-12 12:02:30 +08:00 现在大家吵的“跨域”，其实有两件事。 一是写代码期间，为了让前端程序员能调取任意地址（比如生产机、测试机，甚至隔壁后端同事的电脑）的数据，利用本机的 vite 服务劫持，欺骗了浏览器，实现了类似“跨域”的效果。 这其实不是真正的“跨域”，只是方便写代码，临时开后门而已。 二是代码部署到生产服务器上后，因为某些原因（比如动静分离），前端的代码和后端的代码不在同一个“域”，浏览器就默认你们不是一家人，拦截了请求结果。这时就需要后端配置 HTTP 响应头，告知你们是一家的，让浏览器网开一面。 第一种开后门的“跨域”全程只需前端自己解决，但这只是写代码期间的临时开后门行为，并不是真的解决跨域问题。 而第二种才是真正的跨域，只有后端、运维才能解决的，跟前端没有任何关系。 但某些水平不足的后端混淆了两种“跨域”，遇到同事要求配置 HTTP 响应头的时候，他们百度一下看到了第一种，把开发期间的 hack 当成“解决方案”，反问“你们前端不是可以自己解决吗？”，就把工作甩给前端，自己撒手不管，反倒还说别人是水货了。 |
 | 10 shanhaisilu OP 测试 |
| 11 shanhaisilu OP @shanhaisilu 测试 |
| 12 shanhaisilu OP @DOLLOR 言简意赅，一针见血ｂ(￣￣)ｄ不过作为前端来说，会点 nginx 反代之类的也算是基础要求了，起码得知道 nginx 能解决问题；水货多这个问题前后端都有，还都挺多，都是培训班几个月流水线出来的ε=(ο｀*)))唉 |
| 13 shanhaisilu OP @shadowyue 你要不要看看文章的发布时间，22 年 7 月的文章，我现在还引流？谁引流两年前的东西啊；写的长是因为用了大量的篇幅在写浏览器的路径处理和 vite 的开发服务器配置，跨域的问题一开始几句话就说完了，后边都是解决方案 |
| 14 shanhaisilu OP @tool2dx 没啥办法，毕竟浏览器面对的开发者群体太广了，谁知道有没有人放毒，开发浏览器的时候只能把安全策略定的严格一点；开发客户端好处就是东西都是自己写的，跑的东西自己大体知道都有哪些，不需要太担心有人在自己的东西里运行带毒的东西；不过浏览器还算好的了，各个平台的小程序那是真的糟心 |
| 15 shanhaisilu OP @weixind 毕竟培训班几个月一批，没办法 |
| 16 shanhaisilu OP @victimsss 你确实牛逼，肯定天天都是高精尖功能把，想来肯定很久都没写过变量声明这么简单的东西了吧 |
| 17 shanhaisilu OP @codehz 那你可真棒 ，看看文档就知道全部，知道怎么操作，上手你是一点时间都不用，你开发起来肯定是一路畅通无 bug 的吧 |
 | 18 Rennen 2024-07-12 13:36:23 +08:00 我倒是觉得没看到有人能够讲清楚为啥会有「同源策略」这个多此一举的东西，下面是我的见解 举个例子，有两个网站，网站 A 是一个银行网站，其中有一个查询用户余额信息的 API 接口。 网站 B 是一个毫不相干的第三方网站，和网站 A 不同源。 网站 B 中有一个 Javascript 脚本想要请求网站 A 的查询余额接口。浏览器携带着网站 A 的 Cookie 向网站 A 的后端发送请求，后端接收请求后又向浏览器返回带有余额信息的响应。此时同源策略发挥作用，由于网站 A 和网站 B 不同源，那么响应会被浏览器「截获」，网站 B 中的这个 Javascript 脚本就获取不到这个响应，也就无法知道用户的余额信息。 |
 | 19 paopjian 2024-07-12 20:38:37 +08:00 浏览器的各种安全行为全是在为当初制定的规则打补丁,cookie 这些技术又是不用不行的,只能在两者之中找平衡了, 最终产物就是 跨域控制 HTTPS 这些, 全靠浏览器作为最后一层屏障兜底, 一旦浏览器也被人换了,那可真是直接突破, 所以网吧电脑这种不可控环境能不输密码还是别输密码, 扫码都可能被拦截一层呢, 中间人攻击这种更是轻而易举 |
| 21 shanhaisilu OP @neighbads 准确来说，是 github 的服务器不允许跨域，按照描述，是在自己的网站上调用别人网站的资源，这时候这个所谓的 [调用别人的网站的资源] 准确来说是是 [调用别人网站的服务器的资源] ，数据都是来自服务器的，这时候你的网页的域（不管是协议加域名还是协议加 ip ）和别人的的域（对于 github 的服务器来说就是协议+github 这个域名）肯定是不同的，所以你的网站能否成功调用别人服务器的资源就得看你从对方服务器里获取数据的时候，对方服务器的返回值里有没有跨域相关的字段了，如果没添加，那你的网页就获取不到这个资源，会被浏览器拦截并报跨域错误 不过也不是没办法规避，跨域问题本来就是浏览器和服务器交互的时候才会有的，你可以通过自己的服务器做个中转，先把你的请求发到自己的服务器，然后让自己的服务器去请求 github 的服务器，然后自己的服务器将 github 的返回值再发送给你的网页。这个过程里是服务器与服务器的交互，自然不会被浏览器的跨域问题阻拦住。至于 github 的服务器是否允许你的服务器去请求资源，那就是另一个问题了 |
Select Language