Firebase Storage公开图片部分用户遇SignatureDoesNotMatch访问拒错误

部分用户通过浏览器访问Firebase Storage中的公开图片时，出现访问被拒绝错误，错误码为SignatureDoesNotMatch，提示请求签名不匹配。但大部分用户可正常访问，且这些用户此前能正常下载图片，当前Firebase及Google Cloud无服务中断报告。

问题复现步骤 #

1. 在Firebase控制台的Storage板块点击「Upload file」上传JPEG图片；
2. 点击列表中的图片名称打开侧边栏，再点击图片下方的名称，在新标签页打开图片URL；
3. 复制该URL发送给约百位用户，部分用户在浏览器打开时会出现如下XML错误：

XML file does not appear to have any style information associated with it. The document tree is shown below.

<Error>
<Code>SignatureDoesNotMatch</Code>
<Message>Access denied.</Message>
<Details>The request signature we calculated does not match the signature you provided. Check your Google secret key and signing method.</Details>
<StringToSign>GET 1700048110 /ai-art-7c643.appspot.com/images/2Dc2YVftntdkCqSqQk0L4iI2/d7f4a0c86acca9a7bf6459404a97.jpg</StringToSign>
</Error>

当前环境信息 #

• 示例图片URL：https://firebasestorage.googleapis.com/v0/b/ai-art-7c643.appspot.com/o/FCMImages%2FImpressionist.jpg?alt=media
• 图片通过Firebase控制台上传，无自定义代码
• 约1%用户反馈该问题，本人使用隐身模式或wget可正常打开图片
• Firebase Storage安全规则：

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
        // Everyone can read no one can write (Cloud Functions bypasses rules)
      allow read: if true;
      allow write: if false;
    }

    // Allow the requestor to read or delete or write any resource on a path under the
    // user directory.
    match /users/{userId}/{anyUserFile=**} {
      allow read, delete, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

• 设备时间偏差过大
  错误信息里的1700048110是Unix时间戳，Firebase Storage的签名验证依赖请求时间与服务器时间的同步性，若用户设备时间和标准时间差超过15分钟，就会触发签名不匹配错误。让受影响用户检查并同步系统时间到当地标准时区。

• 代理/缓存服务器篡改请求
  部分用户可能使用了VPN、企业代理或运营商缓存服务器，这类服务可能修改请求中的签名参数或时间戳，导致验证失败。建议用户关闭代理/VPN后直接访问测试。

• 浏览器扩展干扰
  广告拦截器、隐私保护类浏览器扩展可能会修改HTTP请求头或URL参数，破坏签名结构。让用户用浏览器隐身模式（无扩展加载环境）访问，或者临时禁用所有扩展后重试。

• URL复制异常
  少数用户可能复制URL时遗漏了部分参数，或者URL被自动转码/截断（比如包含空格或特殊字符处理错误）。确认用户使用的是从Firebase控制台获取的原始完整URL，没有额外字符或缺失。

• 存储节点临时签名异常
  即使官方无服务中断报告，个别区域的Storage节点可能存在小范围的签名生成/验证异常。可以尝试在Firebase控制台重新生成图片的公开访问URL，或者重新上传图片后分发新链接测试。

• 安全规则优先级确认
  虽然当前规则中match /{allPaths=**}设置了全局公开读，但后续的users路径规则是更具体的匹配，但受影响图片不在users目录下，此因素可能性较低。可确认受影响图片的路径是否符合全局规则的覆盖范围。

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