记录下这份工作后遇到的第一个难题————跨域
当一个请求url的协议、域名、端口三者之间任意一个与当前页面url不同即为跨域。
问题背景:为实现登录功能,通过Ajax调用后台接口时
控制台报错:
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请示在服务端做跨域问题处理
……无果
解决方案:
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隐藏
- }
问题到这里也就解决了,同时也发现一切在代码上出现的问题都不是最难的。
与人建立有效的沟通才是最难的。
致敬锅巴
本文作者为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>