从关键词来看，文件鉴权 / AuthImage / 私有文件 / 对象存储 / 预签名 URL

一、问题场景：你的“私有”文件其实人人都能看到

来看一段最常见的文件上传代码：

@PostMapping
public RespInfo upload {
String url = ossClient.upload。file.getInputStream);return RespInfo.success;// 返回: https://your-bucket.oss-cn-hangzhou.aliyuncs.com/avatars/身份证照片.jpg
}

前端拿着这个 URL 直接塞进 页面完美展示。随后在浏览器无痕窗口粘贴同一 URL，图片依旧可以打开。

主要痛点：

• 浏览器请求 时不携带自定义认证头——JWT、Session Cookie 对这张图片完全失效。
• 任何人拿到 URL 都能直接访问导致数据泄露。
• CDN 会缓存这些图片加速泄漏。
• 搜索引擎可能索引到 OSS 直链公开在互联网上。
• 离职员工的浏览器历史里永远留下这些 URL难以彻底清除。

这不是 OSS 本身的问题，而是把权限控制推给了传输层。Forge Admin 的 forge-starter-file 模块强调：文件访问必须和接口访问一样，经过统一鉴权。

二、方法：AuthImage 鉴权图片组件

直接返回 URL 为什么危险

┌──────────┐ GET /api/file/info/
│ 前端 │ ──────────────────────► │ 后端 │
│ │ ←── { "url": "https://..." } │
└────┬─────┘
│
▼
┌──────────┐
│ 浏览器 │ ───── HTTP GET──► │ OSS │
│ │ ←── OK。图片返回 ────────┘

因为浏览器对跨域 OSS 请求不会自动带上 Authorization/Cookie只要 Bucket 设置为公开读，就会直接返回文件。

AuthImage 的主要思路：不使用外链直接渲染

AuthImage.vue 将渲染过程拆成两步：

1. #1 获取带签名的临时 URL
2. #2 使用 手动带 ` 头拉取文件流 → 转成

使用方式非常简洁：

resolveRenderableFileUrl 三步判断流程

输入这方面，src
├─ 外部直链 / data: / blob:?说起来，→ 直接返回
├─ 否则视为 fileId → 调用 GET /api/file/url/{fileId}?expires=
│ 后端返回临时访问 URL
│ 若返回的是内部代理接口:
│ fetch })
│ → 获取文件流 → URL.createObjectURL → 返回 blob URL
└─ 最终返回同源的 blob URL，可安全在 中使用

*关键点*: 使用  手动注入  头。这正是普通

三、数据结构：文件元数据与存储抽象