ImageFlow.NET Server处理私有Azure Blob Storage需SAS token吗

核心结论 #

不需要为给前端访问的每张图片单独生成SAS token。

实际运行机制 #

ImageFlow.NET Server在这个架构里是作为自有服务端的一层图片处理代理，和Azure Blob的交互全部在服务后端完成，不会把Blob存储的访问路径暴露给前端：

• 你只需要在服务配置阶段，给ImageFlow.NET Server配置私有Blob容器的合法访问凭证即可，支持的凭证形式包括存储账户连接字符串、服务端留存的长期只读SAS、Azure托管身份（需分配存储Blob数据读取权限）。
• 所有前端（含移动端应用）的图片请求全部直接发往你的ImageFlow服务实例，请求只需要携带图片路径、缩放参数等处理规则，不需要携带任何Azure存储相关的访问凭证。
• ImageFlow收到请求后，会用自己持有的存储访问权限从私有Blob容器拉取对应原始图片，在服务端完成缩放、裁剪等处理后，直接把处理完成的图片响应给请求方，处理过程中产生的临时缓存也会留存到你自己指定的存储位置，不会对外暴露原始Blob的访问入口。

对应myimage.jpg缩放请求的实际链路 #

整个流程不需要提前给单张图片生成面向前端的SAS：

1. 前端向ImageFlow服务发起请求，例如https://你的-imageflow服务域名/myimage.jpg?width=480&mode=crop
2. ImageFlow校验请求合法性后，使用自身预配置的存储访问权限，从私有Azure Blob容器拉取原始myimage.jpg文件
3. 服务按照请求参数完成图片缩放处理，命中缓存的场景下会直接返回缓存结果不需要重复拉取原始图
4. 处理完成的图片结果直接响应给前端，整个过程前端不会和Azure Blob Storage产生直接通信

补充提示 #

• 如果你选择用SAS作为ImageFlow访问存储的凭证，只需要生成一个具备容器级只读权限、有效期匹配你服务运维周期的SAS存在服务配置里即可，不需要按单张图、按单次请求反复生成SAS。
• 生产环境优先推荐给ImageFlow服务配置Azure托管身份访问存储，不需要硬编码连接字符串或者长期SAS，权限管控更安全。

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