多租户图片访问应先鉴权再签名

AI 生成的客服报告图片，不能靠「链接够难猜」保护。原文的结论很明确：对象保持私有，由应用确认报告属于当前租户，再签发短期下载链接。存储选型也应围绕数据驻留、恢复能力和运维证据展开。

它值得前端和全栈读者关注的地方，是把一个容易写成「调用 SDK 获取 URL」的功能，还原成完整的权限链路。不过，原文提供的是设计清单和验收方法，没有给出生产压测、成本对照或故障恢复结果。

下载链接之前，必须先回答谁有权访问

一份经过登录验证的报告，需要串起会话身份、租户、报告 ID、对象键、内容类型、大小和保留状态。数据库负责记录这些关系，存储路径只帮助人定位文件。

例如 tenants/t-184/reports/r-9021/summary.png，看起来已经包含租户和报告信息，但应用不能解析用户传来的路径，反过来认定文件归属。路径可以被构造，权限必须来自可信记录。

对象键负责定位文件，数据库记录负责证明归属。

原文给了一个很实用的审查问题：不看 URL，工程师能否解释当前调用者为什么可以读取这个对象？如果图库接口拿到报告 ID 就签名，随后才查租户，即使演示正常，也可能在别人猜中报告 ID 时泄露图片。

服务凭证必须留在服务端。浏览器拿到的应是临时读取权限，而不是可以替其他对象签发权限的凭证。日志也要守住这个边界，不能记录凭证和带签名的查询字符串。

下面的代码解决的是「先查报告、核对租户，再签发链接」。虽然标题强调 Node.js，原文给出的实际代码是 Go，只能作为通用接口契约理解。

package reports

import (
    "context"
    "errors"
    "net/url"
    "time"
)

var ErrForbidden = errors.New("report is not available to this tenant")

type Report struct {
    ID        string
    TenantID  string
    ObjectKey string
}

type Store interface {
    SignGet(ctx context.Context, key string, lifetime time.Duration) (*url.URL, error)
}

type Reports interface {
    Find(ctx context.Context, reportID string) (Report, error)
}

func DownloadURL(ctx context.Context, tenantID, reportID string, reports Reports, store Store) (*url.URL, error) {
    report, err := reports.Find(ctx, reportID)
    if err != nil {
        return nil, err
    }
    if report.TenantID != tenantID {
        return nil, ErrForbidden
    }
    return store.SignGet(ctx, report.ObjectKey, 5*time.Minute)
}

要盯住的是 report.TenantID != tenantID 位于 SignGet 之前。接入 Node.js 时可以保留这个顺序，但还要从可信认证上下文取得 tenantID；这段代码没有展示认证、删除状态检查等完整实现。

五分钟有效期，不能替代撤销与浏览器策略

代码中的 5*time.Minute 是策略示例，不是推荐标准。有效期越长，重复签名越少，但会话变化后的暴露窗口也越长；有效期越短，链接请求越频繁，也更容易遇到过期问题。

具体时长要结合报告敏感程度、预计传输时间和产品承诺决定。原文没有说明某个存储服务究竟在请求开始时检查过期，还是下载过程中继续检查，因此慢速下载的行为需要实测。

签名链接本身不提供即时撤销。

停止签发新链接，和已经发出的链接立即失效，是两件事。若产品承诺用户退出、权限收回或报告删除后马上不可读，就必须验证存储控制能否兑现，不能拿一个短有效期代替承诺。

浏览器直传还多一层 CORS。拿到预签名上传地址，不代表页面就能上传成功；存储端必须允许对应来源、方法和请求头。应从真实生产来源跑端到端验证。策略无法表达或无法验证时，原文建议采用服务端中转上传。

上线证据要覆盖迁移、恢复和并发写入

原文把 US 或 EU 视为一份书面控制要求的输入。需要记录的包括对象存放位置、报告生成位置、客户请求服务位置、支持人员能否访问，以及允许哪些数据传输。控制台上的一个区域标签不够。

S3-compatible 也需要落到实际接口上：私有上传、元数据查询、签名下载、删除，以及大图片需要时的分片上传完成操作，都要逐项测试。

容量估算则要包含每天报告数、每份报告图片数、对象大小中位数与最大值、读取次数、每次会话请求链接次数、保留天数和清理延迟。热门图库与生成重试形成的突发流量，应单独建模。原文没有给出这些变量的实测值，因此不能据此推导具体账单。

服务等级目标（SLO）同样要按用户结果拆分。存储桶能访问，不等于用户能拿到正确报告。链接签发、报告生成、删除、清理和承诺的撤销行为，都需要各自的目标；监控则关注签发延迟、下载结果、429 响应、过期投诉、孤儿对象存续时间和删除失败。

恢复能力也不能省略。唯一报告 ID 可以减少误复用对象键，却不能恢复被覆盖的内容。如果要求版本控制或对象锁，而服务不支持，就需要独立恢复副本，或者更换服务。

验收时还要让两个 worker 同时写同一份报告，明确第二次写入是拒绝、复用已有结果，还是产生新版本。静默采用最后一次写入，实际上是在替产品做决定。

迁移演练需要从权威报告记录复制对象，核对数量和哈希，验证目标区域的数据驻留要求及突发流量下的读取 SLO，再切换链接签发。回滚时停止新链接、暂停或排空写入、保留报告与对象键的映射，并在约定窗口保留旧读取路径。把桶改成公开读取，会直接改变权限模型。

我的判断

这套方案最有价值的地方，是把授权放回应用，把存储兼容性变成可以验收的操作。对于需要登录、按租户隔离的报告，规则清晰，也方便审查。

但它仍是一份设计建议，没有展示作者团队的实测数据。五分钟是否合适、签发接口能扛多少流量、哪个费用项占大头、迁移多久能恢复，原文都没有证据。不能因为清单完整，就默认某个服务已经满足要求。

代码与标题之间也有落差：它解释了控制顺序，却没有提供 Node.js SDK 接入示例。读者可以直接借用设计，不能直接把它当成完整工程方案。

适用范围要守住。永久公开图片、静态站点和匿名 CDN 分发，需要独立的交付层，并考虑缓存失效和滥用控制。服务端中转则是原文给出的上传备选方式，但两者的成本与性能没有对照数据，仍需按团队约束验证。

能拿来做什么

• 给现有 Node.js 下载接口做一次顺序检查：从认证上下文取得租户，查询报告归属和可用状态，通过后才调用签名适配器，并保留数据库中的报告与对象映射。
• 给前端上传补一组真实来源下的 CORS 验证，覆盖允许的方法和请求头，同时测试最小样例与最大允许图片，避免只用命令行上传成功就判定可用。
• 在非生产租户跑通归属用户成功、其他租户无链接、删除后不能新签发、过期链接失效四类检查；用 AI 编程助手补接口时，也把这些行为写进验收要求。
• 发布前补做双 worker 写入和迁移回滚演练，记录冲突策略、数量与哈希校验结果，以及停止签发新链接后旧链接的实际行为。