学习 · 2020年4月22日 1

前后端分离跨域问题

记录下这份工作后遇到的第一个难题————跨域

当一个请求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]致敬锅巴