请教一个图片上传后但不提交,如何回收的问题?

场景如下:

前后端分离模式,使用 token 验证用户身份

用户操作:

在富文本编辑器中用户上传图片,此时走后端的上传接口,通过 Storage 存储图片,返回一个 url 链接地址,用户可以通过审查元素看见这个链接地址。

问题:

如果用户上传了一个图片 a.jpg 之后,但是没有提交此次编辑的富文本,那这张图片怎么办?用户是可以看见 a.jpgurl 地址的,这样的话容易被恶意用户拿来当 图床,但这都是小问题。

更大的问题是,如果恶意用户使用脚本通过这个图片上传接口不停的向服务端上传图片,应该怎么处理?


以前做富文本编辑的时候上传图片,如果用户不保存此次编辑,我也不会管这张图片的回收,如果是为了防止用户做图床还可以加个 refer 防盗链,但如果就是不停的向文件上传接口上传垃圾文件呢?应该怎么防范?我今天突然想到了这个问题,想请教一下大家都是怎么做的?谢谢

我从未见过一个早起、勤奋、谨慎,诚实的人抱怨命运。
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
laravel_peng
最佳答案

问题一: 如果用户上传了一个图片 a.jpg 之后,但是没有提交此次编辑的富文本,那这张图片怎么办?

  • 其实你给出了一个思路:图片的回收。
  • 但是如何回收呢?这个需要做一个区分。
    • 哪些图片链接是富文本编辑器提交的有效链接。(有效的标记保留)
    • 哪些图片链接是富文本编辑器未提交的无效链接。(无效的定时回收,其实也就是删除,避免占用磁盘空间资源)
  • 那又该怎么标记呢?
    • 数据库方案:之前 L03 Laravel教程 有一个图片资源表,记录的是所有客户端上传的图片资源及其路径位置,在这表新增有效字段可以标记图片的有效性。同时资源的有效性,需要在富文本中查找是否真正的使用,使用的标记有效就行,无效的定时删除记录和对应的图片资源。
    • Redis 或缓存方案:和数据库方案类似,不过它无需新增数据表。

问题二:用户是可以看见 a.jpg 的 url 地址的,这样的话容易被恶意用户拿来当图床!

  • 其实你给出了一个答案:防止用户做图床还可以加个 refer 防盗链。
  • 更麻烦的方案是:加一个临时 token 才能访问资源,这个类似于阿里云 OSS 的 sts 临时票据验证。

问题三:如果恶意用户使用脚本通过这个图片上传接口不停的向服务端上传图片,应该怎么处理?

  • 这个就做节流限制:针对 ip 或针对用户,每天可上传的图片数量,达到一定量进行提示无过量上传。
3周前 评论
MArtian (楼主) 3周前
讨论数量: 8

如果严谨一点,上传是不可以直接到富文本的,都是有一个上传管理,类似微信素材,你可以上传到素材中心,然后在使用,百度编辑器也可以使用图集,不过没做限制

3周前 评论

加上防盗链之后,用户上传之后他站也用不了,没啥意义。唯一的担心就是上传太多而不用,做下限制即可

3周前 评论

如果想防止别人一直刷接口,可以在请求接口的时候增加签名(每次请求都是唯一的),签名生成规则只有前后端知道。如请求来时判断前端生成的签名是否正确。正确则走正常逻辑

3周前 评论

可以上传的文件存缓存,富文本被保存的时候才存文件系统

3周前 评论

单纯存储文件来说哈,可以分两步,文件上传到临时文件夹(按日期建立文件夹),文章保存时提交临时路径然后move到正式的路径保存。最后按日定时清理临时文件夹

3周前 评论

上传后,延时删除。提交后,清理延时任务。

3周前 评论
laravel_peng

问题一: 如果用户上传了一个图片 a.jpg 之后,但是没有提交此次编辑的富文本,那这张图片怎么办?

  • 其实你给出了一个思路:图片的回收。
  • 但是如何回收呢?这个需要做一个区分。
    • 哪些图片链接是富文本编辑器提交的有效链接。(有效的标记保留)
    • 哪些图片链接是富文本编辑器未提交的无效链接。(无效的定时回收,其实也就是删除,避免占用磁盘空间资源)
  • 那又该怎么标记呢?
    • 数据库方案:之前 L03 Laravel教程 有一个图片资源表,记录的是所有客户端上传的图片资源及其路径位置,在这表新增有效字段可以标记图片的有效性。同时资源的有效性,需要在富文本中查找是否真正的使用,使用的标记有效就行,无效的定时删除记录和对应的图片资源。
    • Redis 或缓存方案:和数据库方案类似,不过它无需新增数据表。

问题二:用户是可以看见 a.jpg 的 url 地址的,这样的话容易被恶意用户拿来当图床!

  • 其实你给出了一个答案:防止用户做图床还可以加个 refer 防盗链。
  • 更麻烦的方案是:加一个临时 token 才能访问资源,这个类似于阿里云 OSS 的 sts 临时票据验证。

问题三:如果恶意用户使用脚本通过这个图片上传接口不停的向服务端上传图片,应该怎么处理?

  • 这个就做节流限制:针对 ip 或针对用户,每天可上传的图片数量,达到一定量进行提示无过量上传。
3周前 评论
MArtian (楼主) 3周前

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!