在前后端分离的工程中,前后端通信链路由前端调用后端,变成了前端–>api gateway–>后端,那么前端在加载一些私有资源(需要权限,需要认证)等文件时会存在无法传入token的问题 本文是针对前端加载资源的随想

  • 未前后端分离调用链路

    前端 ------> 后端 ------> 返回结果到前端

  • 前后端分离调用链路

    前端 ------> API gateway ------> 后端 ------> 前端

解决方案列表

在前端加载一些文件,例如图片,浏览器会根据image标签的src属性自动获取图片的二进制流,浏览器在加载图片时,不会带上token在header中,一切都是浏览器默认行为,所以此处无法利用浏览器默认行为加载私有文件,所以提出了以下几种解决方案.

  • 前端ajax加载,后端返回base64,前端再做处理
  • 前端在url中加入token,传入到后端
  • 前端获取token,存入cookie,后端根据优先级来获取token

下面我们分别来说说这三种方案.

前端ajax加载,后端返回base64,前端再做处理

链路图如下:

前端ajax ------> API gateway ------> 后端base64 ------> 前端设置图片base64

前端:使用ajax加载图片,ajax中带上token等认证信息 后端:在接收到请求后,将图片转为base64字符串,通过response返回至前端 前端:在接收到后端返回后,将base64设置至相关的image中

  • 优点:
  • 遵循原有token机制

  • 可解决加载机制

  • 缺点:

  • base64在后端转换增加了后端压力

  • base64在前端处理较为麻烦(如果有大量图片,容易产生阻塞)

  • 整个链路复杂度太高了,涉及到很多流的操作

  • 其他类型的文件无法满足此需求

前端在url中加入token,传入到后端

链路图如下:

前端修改图片url ------> API gateway ------> 后端返回图片二进制

前端:在加载图片时,先修改图片的url,带上token参数 后端:在接收到请求后返回图片二进制

  • 优点:
  • 前端没有上一个方案那么复杂
  • 后端也简单了很多

  • 可以加载其他类型文件

  • 缺点:

  • 在大量图片的情况下,整体表现还是不好,因为每次要修改图片url

那么有没有一个前端做的事情少,后端也不那么复杂的方案呢?

前端获取token,存入cookie,后端根据优先级来获取token (推荐)

在前面两种方案中,都涉及到一个共同的地方,那就是需要多认证鉴权做一定的兼容处理 > 方案1:虽然可以满足token机制,但弊端太大 > 方案2:token的获取需要修改 结合两种方案,既然token机制不能满足,那么一个新的想法油然而生,链路如下:

链路1:

登录 ------> API gateway ------> 返回token ------> 存入cookie

链路1:前端在登录后,将认证服务返回的token 存入cookie中,作为一个兼容的方案来使用

链路2:

前端加载图片 ------> API gateway ------> 后端返回图片二进制

链路2:前端按照浏览器默认行为加载图片,此时浏览器默认会带上cookie,但是不会带上token,API gateway在收到请求后,根据优先级,先后读取header中的token,cookie中的token,如果是加载其他类型的文件并且header中的token为空,那么则使用cookie中的token进行认证鉴权,认证通过后转发到相应的后端服务进行资源加载,返回至前端

  • 优点:
  • 前端除了链路1的处理,其余全为默认行为
  • 资源服务器不做修改
  • API gateway增加了认证兼容性

  • 前端没有对资源加载的修改,存入cookie的方式也有利于前端的整体控制

  • 缺点:

  • 需要修改认证

  • 前端附加了一个cookie存储的需求(针对app)

以上几种方案各有利弊,在使用时择情采用,毕竟代码是死的,思想是活的.