Storage Explorer生成的SAS用于外部Webhook时出现认证错误求助

• 核对SAS参数与请求的一致性
  确认生成SAS时设置的权限（比如是否包含w写入权限）、服务类型（Blob/File等）、资源路径，和客户上传的目标完全匹配。比如SAS是针对特定Blob容器的，客户就不能上传到其他容器；如果是单个Blob的SAS，上传路径不能出错。另外要注意SAS里的sv（服务版本），得和客户用的SDK/工具版本兼容，低版本服务版本可能导致签名算法不匹配。

• 验证SAS的编码与传递完整性
  让客户确认整个SAS字符串（从?sv=开始）完整附加在请求URL后面，没有被截断或错误转义。尤其是+、/、=这类特殊字符，有些工具会自动转义，直接导致签名验证失败。可以让客户把实际请求的URL（隐去敏感信息）和你生成的SAS对比，排查编码差异。

• 检查请求方法与SAS权限的匹配度
  如果客户用PUT方法上传，SAS必须包含写入权限；如果是用POST表单上传，还要确认SAS是否启用了对应的权限和签名版本。另外要核对Webhook的请求方法是否在SAS允许的权限范围内，别出现权限不覆盖请求方法的情况。

• 确认SAS的资源范围是否正确
  要是给容器生成的SAS，客户的上传路径必须在该容器下；如果是存储账户级别的SAS，要检查是否指定了正确的服务类型（比如只开了Blob服务的话，不能用来操作File存储）。另外，Storage Explorer生成SAS时，如果客户是通过代理访问，要勾选“允许代理请求”，部分代理会修改请求头导致签名验证失败。

• 排查请求中的额外自定义头
  使用SAS认证时，部分自定义请求头（比如x-ms-meta-*这类自定义元数据）会被纳入签名计算。如果客户的请求加了这类额外头，但生成SAS时没指定要包含这些头，就会出现签名不匹配。可以让客户先去掉不必要的自定义头，或者生成SAS时明确指定需要包含的头字段。

• 换工具重新生成SAS并测试
  有时候Storage Explorer可能因为缓存或配置问题生成异常SAS，建议用Azure CLI或PowerShell重新生成，比如CLI命令：

  az storage container generate-sas --name <容器名称> --account-name <存储账户名> --permissions w --expiry <过期时间> --https-only
  

  先自己用Postman这类工具测试这个新SAS能正常上传，再给客户使用，排除工具生成的问题。

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