记录下这份工作后遇到的第一个难题————跨域
当一个请求url的协议、域名、端口三者之间任意一个与当前页面url不同即为跨域。
问题背景:为实现登录功能,通过Ajax调用后台接口时[aru_39]
控制台报错:
Access to XMLHttpRequest at 'http://xxxx/api/auth/jwt/token' from origin 'http://localhost:63342' 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.
直译过来:
通过CORS策略已阻止从来源xxxxx访问 xxxx处的XMLHttpRequest对预检请求的响应未通过访问控制检查,所请求的资源上没有Access-Control-Allow-Origin标头
也就是说,设置下Access-Control-Allow-Origin的标头就可以通过检查吗?
Access-Control-Allow-Origin是什么?
是HTML5中定义的一种解决资源跨域的策略。
通过服务器端返回带有Access-Control-Allow-Origin标识的Response header,可用来解决资源的跨域权限问题。
OK,找到后台人员001请示在服务端做跨域问题处理
……无果[aru_19]
解决方案:
Nginx反向代理,通过配置指定到IP将请求转发给指定服务器处理。
代理:就是在我们和真实服务器之间有一台代理服务器,发出的所有请求都是通过它来进行转接
正向代理:假设正常情况下访问不了Google,但可利用vps访问Google,通过vps再将数据传回来。
反向代理:通过访问反向代理服务器,在无需知道真实目标地址的情况下将请求发送到目标服务器。
location /api{ add_header 'Access-Control-Allow-Origin' '*'; //允许所有来源访问 add_header 'Access-Control-Allow-Methods' 'GET, POST,OPTIONS, PUT, DELETE' always; //允许访问的方式 add_header 'Access-Control-Allow-Credentials' 'true' always; //服务端下发到客户端的response中头部字段,意义是允许客户端携带验证信息,例如cookie之类的 add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type,Accept,Origin,User- Agent,DNT,Cache-Control,X-Mx-ReqToken,X-Data-Type,X- Requested-With,X-Data-Type,X-Auth-Token' always; if ( $request_method = 'OPTIONS' ) { return 200; } proxy_pass http://xxx.xxx.x.37:8888/api; //将请求反向代理到 URL 参数指定的服务器上 proxy_hide_header Access-Control-Allow-Origin; //此处因后台人员跨域处理不当,需将代理处的Origin隐藏 }
问题到这里也就解决了,同时也发现一切在代码上出现的问题都不是最难的。
与人建立有效的沟通才是最难的。
[aru_12]致敬锅巴
本文作者为MingJun,转载请注明。
棒棒哒
I like this web blog very much, Its a very nice situation to
read and find information.<a href="http://suderman.com/__media__/js/netsoltrademark.php?d=www.blogexpander.com" rel="nofollow ugc">Blog monetyze</a>