这几天也在使用 oss，今天问了阿里技术人员，争对一系列大致做了这么几种流程处理方案

争对这个要利用好两个东西，一个是回调，一个是 policy 参数

我现在做的方法是让他一次签名只能上传一个文件，通过在 policy 里面设置 content-length-range(文件大小限制)和 key(文件路径)，来控制用户的上传策略，如果严格一点还可以设置必须让用户上传的文件类型

例如：
content-length-range=524288 字节
key=/user/logo/3f7a68dbfa984a189f80612343064f32.png

在前端，用户也只能设置相同参数才能上传，不管黑客是怎么拿到的这个签名，他始终得保证，文件大小在 512kb 内，以及上传到 oss 最终的名称会是 /user/logo/3f7a68dbfa984a189f80612343064f32.png

再者，为了防止黑客调用脚本疯狂上传，我觉得这个并不应该把他算在 oss 这边，首先，黑客要拿到签名，你为什么会给他呢？肯定是他是你网站的用户，在你程序没有 bug 的情况下，他是通过正常流程获取到的，争对你自己网站上的用户，你可以给他规定权限，比如这个用户他只有 1 个 G 的空间，在上传文件前其实我们能知道文件大小的，那么我们可以在获取签名的时候减去他的可上传空间，满足条件才给他下发签名

至于如何做知道是哪个用户上传的，我觉得你可以在文件名上做手脚，比如用户 id 为 1，获取签名得到文件名值 3f7a68dbfa984a189f80612343064f32.png ，那么在下发的时候是否可以以文件名为 key，id 为 value 临时储存在 redis 来做一个关联呢，这样上传成功之后，通过 oss 的回调里的文件名参数，我们就能找到用户，这样肯定能判断具体是哪个用户上传的，如果还不能判断，那说明至少是程序这边出现了权限上的 bug，问题还是我们自己

还有一个签名可以做一些小处理，比如一个签名可以规定 3 秒钟有效，其实这个也无所谓了，就算是 30 分钟过期，黑客拿着这个，他也只能局限在我们策略内的文件大小和文件名及特定格式操作，就算在这个签名内他连续上传，也只会是覆盖那同一张图片，所以造不成什么威胁，他就算在 30 分钟内上传 100 万张图片，也只玩的是那一张图片，512kb，一直做的覆盖操作，关键是，他请求的是阿里的服务器，oss 内 /外网流入流量是免费的我们更不需担心

所以只要我们自己把关好自己系统这边的逻辑，直传这种方式我觉得是使用 oss 最好的方式，毕竟我实在不喜欢图片上传还要走一遍自己服务器