前端跨域的解决方案——代理

场景

前端本地开发,接口代理,页面代理,文件代理

  • 本地开发时可封装统一的request方法,针对接口请求统一加上/api前缀。针对一些特定场景如APP内嵌H5项目,通过Bridge传入的参数,或者获取参数的方法,每次请求都需附带则可以通过拦截器针对请求前的参数进行修改, 在此处也可针对特定地址的接口进行特定的调整。而返回值的错误处理,如非正常状态的HTTP Status错误处理,可在response中进行拦截,如会话失效返回的401捕捉并进行重定向到登陆页面。
  • 跨域有多种解决方案,但是代理是其中较为简单且解决比较完善的方案。

  1. 本地开发使用的各种前端脚手架,基本支持Proxy的配置,结合上文request方法统一加上的/api前缀,可在Proxy中直接针对/api路径进行代理配置,changeOrigin并且target到指定的后端接口url。不同环境的baseUrl也就无需配置。开发时不同环境的后端接口可能会出现不同,可通过CROSS ENV注入环境变量,针对环境变量维护一份接口地址Map,如:

    export const targetUrl = {
      dev: 'DEV_API_BASE_URL',
      test: 'TEST_API_BASE_URL',
      uat: 'UAT_API_BASE_URL',
    }

2.针对可能出现的iframe嵌套进组件的需求,也可以单独部署到其他服务器,如专门的pdf预览用页面,iframe的跨域问题和pdf文件的跨域问题,都可以通过配置Proxy来解决,如设置前缀/viewer/file代理到对应的页面服务器与OSS文件服务器。

注意,目前涉及到的代理都是本地开发时候的脚手架提供的代理能力,部署后将失效,需要在服务端配置代理,一般使用Nginx的反向代理能力。


3.部署。部署涉及到的代理与本地的Proxy基本一一对应,可参考如下Nginx反向代理配置。

location ^~/api/ {
  proxy_pass API_BASE_URL;
}

注意斜杠。实际上反向代理是屏蔽了服务端,拦截了前端项目的访问路径,通过本机Nginx代理到不同目标服务器,这一过程对客户端来说是无感知的。而正向代理则刚好相反,代理了客户端,服务端对不同客户端是无感知。

tag(s): 技术
show comments · back · home
Edit with markdown