前端人员能独自解决掉跨域问题吗?
今天,一群前端同事围着我,让我这个“前端大佬”解决跨域的问题,我也是前端。 我紧张的要命。
浏览器里接口请求不通,如下报错:
Access to fetch at 'https://cmps.test.ceenk.com:9001/mgw.htm' from origin 'http://111.205.51.131:8876' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
请问,我有办法解决吗?
另外问一下,跨域问题是否与前端有关系?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(11)
不能哦,想想如果你不需要支付宝同意,在你的网站就可以代替用户去调用支付宝接口,那不是乱了套了
跨域必须要后端进行一定的支持
这个问题得从两个方面来说:
开发环境 可以利用 WebPack Proxy 解决跨域问题(或者任何能在本地部署反向代理的服务),更简单点测试环境提供允许跨域的后端服务
生产环境 只能用一个不健康的形式了,见9种常见的前端跨域解决方案(详解)
要么不跨域,要么让所访问的服务允许跨域即可
跨域问题的本质是什么?
就是浏览器禁止了,不让非同源的请求通过,理论上来说,跟前端没半点关系,需要接口层面返回允许跨域的请求头
怎么做呢良心建议是甩给后端,这不是我前端的锅,这是一劳永逸的办法,1本来就是后端的事情,为什么要前端揽下来,2增加了前端开发成本,想对于后端响应头加几个字段,前端要另外维护一个服务
另外看到底是不是跨域问题要看接口返回的响应头,因为有些接口错误404之类的在控制台报的错也是跨域一样的错
前端自己解决的方法:
webpack 配置 proxy server代理
nginx 配置
自建一个node,使用三方库或者手写代理
总结就是尽量让后端做,实在不行自己建一个服务 -> 这个服务允许跨域 -> 转发到真正后端,绕过浏览器
如果仅仅是解决开发时的问题,很容易,而且方式很多.
但如果是线上解决.就不应该由前端解决,要么后端设置cors,要么运维配置代理.要么前后协商用jsonp.要么,前端页面与API网站放到一起(这也是最自然的方式,也是最省心的方式,没事拆开干嘛?);
还有种方式.找前端页面所部署的网站负责人.设置一个接口,该接口接受url,mehtod,data等等,负责把页面请求透传到指定API网站,就相当于把devserver.proxy搬到线上了.这种方式也是与其他公司通信的一种方案.
别折腾了,让后端加就完事了
前端折腾,部署到线上怎么办?多此一举
谢谢各位回答,我记录一下这个本地临时调试的方式:
关闭浏览器同源策略的方法
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --args --disable-web-security --user-data-dir="C:\abc"
》保存。
如果你前后端分离,并且前端自己部署,那当然可以。
解决跨域除去了jsonp等一些难以根治的处理方法(JSONP只支持src属性发出的get请求,对于其它更丰富的请求无能为力),剩下的无外乎两种:
其中客户端自己能做的话那就是代理。
应该理解,跨域是浏览器的同源策略所限制,对于脚本请求并不限制,因此你可以用脚本转发请求绕过跨域这个问题,是为代理————nginx这样的服务器本身支持简单配置即可实现代理。
楼上说的都是正确的。补充一个开发环境简单的跨域处理:chrome插件Allow CORS: Access-Control-Allow-Origin
不错学习一下
都增加额外的开销