通过Azure AD认证的Azure Blob Storage私有资源如何在img标签中加载

核心问题答复 #

不能直接在<img>标签的src属性中发起带自定义Authorization头的请求。这是浏览器原生资源加载的标准限制：<img>标签发起的GET请求仅支持自动携带Cookie类凭证，不允许通过src属性注入自定义请求头，无通用变通空间。

可行实现方案 #

• 方案1：前端动态拉取Blob转换本地URL
  不需要修改后端逻辑，仅调整Quill内容的渲染流程即可：

  1. 数据库持久化存储不带任何认证参数的原始Azure Blob地址
  2. 从数据库取出HTML内容渲染到Quill前，先解析DOM提取所有<img>标签的原始src
  3. 用fetchAPI请求对应Blob地址，请求时手动在头中带入Azure AD的Bearer令牌
  4. 拿到响应的二进制Blob对象后，调用URL.createObjectURL(blob)生成临时本地URL，替换原img的src
  5. 页面/组件销毁时调用URL.revokeObjectURL()释放内存，避免泄漏
     优势：无后端改造量，数据持久化逻辑完全不需要改动。

• 方案2：后端代理转发（你原思路的落地方案）
  把认证逻辑收敛在后端，安全性更高：

  1. 后端新增代理接口，例如GET /api/blob-proxy?path={blob原始路径}，接口先校验当前用户的登录权限，再由后端携带Azure AD令牌请求私有Blob资源，将二进制内容和响应头原样返回给前端
  2. 渲染Quill内容前，统一把所有img的原始Blob地址替换为代理接口地址即可，例如将https://<account>.blob.core.windows.net/<container>/<img-name>替换为/api/blob-proxy?path=<container>/<img-name>
     优势：前端不需要处理Azure令牌的有效期、跨域等问题，适合对安全要求高的场景。

• 方案3：短有效期SAS动态拼接
  性能最优，不需要占用后端服务带宽：

  1. 数据库依然存储不带SAS的原始Blob地址
  2. 每次渲染Quill内容前，前端批量提取所有Blob路径传给后端，后端为每个合法的Blob生成有效期1小时以内的短有效期SAS令牌返回给前端
  3. 前端将SAS拼接到对应img的src后即可直接访问
     优势：请求直接走Azure存储节点，不需要经过你的后端转发，带宽压力极小，短有效期SAS也不会有明显的安全风险。

内容的提问来源于stack exchange，提问作者Clumpsypenguin