• 静态文件鉴权


    静态文件鉴权的解决方案

    背景介绍

    XX业务系统作为BXX业务系统的孪生姐妹系统,是对BXX受理业务的强力补充系统,他允许操作员拿着IPAD,和客户约定地点上门受理业务。

    因一些业务的受理,按照最新的业务规章制度,需要客户观看XX视频方可受理,我们现阶段,视频文件的URL是直接暴露在公网上,通过URL是可以直接浏览相关的视频文件,由此引申出了静态文件鉴权的需求。

    客户需求

    接到XX客户的需求,他们要求暴露在互联网公网的视频的URL,不能在浏览器中直接输入地址访问,因为视频内容属于较敏感的内容,需要保护,要求增加操作员登录认证机制。

    解决方案

    一、response输出流

    拿到需求,我首先想到的就是通过response.getOutputStream().write输出文件流的方式来解决此问题,但是立马被组内前端人员否决掉,此方案会影响前端体验。在体验为王的时代,此方案确实不妥,后端Java接口,首先需要从文件服务器获取相应的文件,然后再通过response写流的方式输出,此方案会有一个文件服务器获取步骤,对比公网直接访问,相关于多了一次文件流的流转动作,这样就会造成前端的卡顿感,并且文件预览的功能,估计也拜拜了。此方案——NO PASS!

    二、静态文件鉴权

    在我的认知中,我绝对不会是第一个有这需求的人,世界这么大,我要去问问。于是,“静态文件鉴权”六个字在我脑海中浮现,我毫不犹豫在百度的搜索框中输入这六个大字,相关解决方案的文章尽在眼底,通过相关知识的消化、吸收、本地Demo的模拟、开发环境的测试,最终验证了静态文件鉴权的可行性。最终的结果,虽然看似简单,几行代码,几行配置就解决了相关问题,但是其中还是走了不少弯路,好在消化吸收总结了。

    三、OpenResty解决方案

    OpenResty是一个基于Nginx与Lua的高性能Web平台,相当于二次封装了nginx,并且集成了lua脚本,开发人员只需要简单的编写lua的脚本,就可以实现静态文件鉴权的相关的逻辑了。

    百度下载

    1. openresty-1.21.4.3-win64.zip——主程序
    2. lua-resty-http-master.zip——让lua脚本支持http发包

    解压openresty本地目录,发现此软件真的就是在nginx上包了一层,替换ngnix成本极小。 启动命令,配置文件,都与ngnix一模一样。

    解压lua-resty-http,将\lib\resty\目录下http*.lua的三个文件copy至openresty\lualib\resty\目录下,即可让lua脚本支持http发包。

    修改配置nginx.conf,在server中增加相应的location,我这里映射了所有mp4结尾的请求

    Lua脚本:

    可以看到脚本非常简单,Lua中..是连接字符串的意思。

    Controller:

    我这里仅仅是为了验证可行性,所以就写死了判断,这里的返回值内容,会在Lua脚本中用到。

    访问成功效果:

    可以看到url中,带了?token=123456,视频正常播放。

    访问失败效果:

    我输入错误的token,或者不输入token,静态文件的访问被拦截了。

    通过上面的模拟,此方案已经可以满足客户的需求了。

    四、ngnix解决方案

    当我将OpenResty解决方案向领导汇报时,立马被泼了一盆冷水,理由很简单,客户不会轻易同意替换ngnix,不可控的风险太大,日后出现问题的维护成本太高。虽然我据理力争,终究是未站在客户的角度考虑问题,所以我也只能接受领导的建议,寻找ngnix的解决方案。

    Ngnix也能支持Lua脚本,但是需要重新编译才能支持Lua脚本。默认情况下,Nginx并不直接支持Lua脚本。要使其支持Lua脚本,需要进行一些额外的配置和编译步骤。对我来说,研究重新编译Ngnix的成本与风险,还真不如直接使用OpenResty,所以Ngnix支持Lua脚本的方案也被我自己否决了。

    最后,绞尽脑汁,在百度,ChatGpt的帮助下,ngnix经过无数次的改配置,启动与重启中,终于在不依赖Lua脚本的前提下,也有了对应的解决方案。

    修改ngnix.conf配置文件 :

    token传参这里,卡了好久,经过反复试验,终于往header中增加url路径的方式测试成功,后端成功取到参数。

    X-Original-URI是一个非标准的HTTP报文头,其作用是使用该报文头的值中所指定的URL覆盖请求目标中的URL。该报文头通常在代理服务器或负载均衡器中使用,用于记录原始请求的URL,以便在后续的处理中能够获取到原始的请求信息。然而,由于该报文头并非标准的HTTP报文头,因此不是所有的代理服务器或负载均衡器都支持该报文头。好在ngnix支持了该报文头。

    Java后端改造:

    注意取到的X-Original-URI的内容,取到的内容,需要拆分字符串,提取token,我这里简单验证可行性,就没这些逻辑,简单判断下是否相等即可。Ngnix验证token失败,HTTP的响应码需要不为200,所以我这里抛出了异常。

    访问成功效果:

    访问失败效果:

  • 相关阅读:
    【mysql学习笔记29】触发器
    游戏模板:MFPS 2.0: Multiplayer FPS
    蓝牙 or 2.4G or 5.8G?你会选择耳机吗
    2205,2228,2230,2238,2292
    CMake Cookbook笔记(11/19未完待续)
    什么是DeFi流动性资金池
    LeetCode24.两两交换链表中的节点
    C++函数对象包装器function类详解
    STM32单片机中国象棋TFT触摸屏小游戏
    微软二面:既然有 HTTP 协议,为什么还要有 RPC?
  • 原文地址:https://blog.csdn.net/zhanghaidang/article/details/134510811