静态文件鉴权的解决方案
背景介绍
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的脚本，就可以实现静态文件鉴权的相关的逻辑了。
百度下载
- openresty-1.21.4.3-win64.zip------主程序
- 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，所以我这里抛出了异常。
访问成功效果：
访问失败效果：
