HTTP POST浏览器上传遇AccessDenied错误：策略已过期求助

我来帮你梳理下这个问题——我之前也碰到过明明设置了未来过期时间，却还是报AccessDenied: Policy expired的情况，大概率是这几个细节没处理好：

• 严格检查Policy的时间格式
  绝大多数云存储服务要求expiration字段必须是UTC时间，且严格遵循ISO 8601格式，比如2019-06-20T14:30:00Z。如果你只写了2019-06-20或者没加Z后缀，服务端可能会把它当成本地时间解析，导致实际已过期。举个例子：你本地是东八区时间2019-06-20 22:30，对应的UTC时间是14:30，如果你写2019-06-20T22:30:00（没加Z），服务端会认为这是UTC时间，此时本地22:30的时候，UTC已经过了22:30，自然会报过期。

• 修改Policy后必须重新生成签名
  Post Policy的签名是基于整个Policy字符串生成的（比如HMAC-SHA1算法），如果你只是修改了expiration字段，但复用了之前的旧签名，服务端验证时会因为签名不匹配，返回类似过期的错误（有些服务的错误提示会有误导性）。每次调整Policy内容后，一定要重新计算签名，确保Policy和签名是一一对应的。

• 确保服务器时钟同步（重点！）
  如果你是通过后端服务生成Policy，那要重点检查后端服务器的时钟是否和网络时间同步。如果后端时钟快于实际时间，生成的Policy过期时间在云存储服务端看来已经过期，哪怕你设置了未来1年也没用。可以用命令验证：

  • Linux/macOS：执行 date -u 查看UTC时间，对比网络上的UTC时间
  • Windows：执行 Get-Date -Utc 查看UTC时间

• 排查Policy的其他约束项
  有时候报错提示是“Policy expired”，但实际是其他约束条件不满足，比如content-length-range设置的范围太小，或者key的格式不符合规则，服务端返回的错误信息可能不准确。建议把完整的Policy内容（敏感信息打码）贴出来，看看有没有其他可能的问题。

• 确认云存储服务的规则匹配
  不同云服务商的Post Policy规则有差异，比如AWS S3和阿里云OSS的签名算法、Policy字段要求都不一样。要确保你是按照对应服务商的官方文档来生成Policy和签名的，不要混用不同服务商的规则。

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