Firebase Storage规则中crc32c哈希格式及写入权限问题咨询

你遇到的权限拒绝问题，核心原因是request.resource.crc32c的格式和你路径中hash参数的格式不匹配。我来帮你理清细节并给出解决方案：

首先明确request.resource.crc32c的格式 #

Firebase Storage中的request.resource.crc32c是Base64编码的字符串，它和Google Cloud Storage（GCS）中存储对象的crc32c元数据格式完全一致——对应文件内容CRC32C校验和的4字节序列的Base64编码（带标准填充，比如EjRWFA==这类格式）。

举个实际例子：如果某个文件的CRC32C校验和是十六进制的0x12345678，对应的4字节大端序列是0x12, 0x34, 0x56, 0x78，Base64编码后就是EjRWFA==，这就是request.resource.crc32c会返回的值。

你的规则为什么会失败？ #

假设你路径中的hash参数是十六进制字符串（比如12345678）、整数或者其他格式，直接和Base64格式的request.resource.crc32c比较，结果肯定不相等，导致权限校验失败。

解决方案：统一格式进行比较 #

根据你路径中hash的实际格式，在规则中做格式转换：

场景1：路径中的hash是十六进制字符串 #

如果你的hash是CRC32C校验和的十六进制表示（比如12345678），可以用Firebase规则的内置函数把它转换成Base64格式，再和request.resource.crc32c比较：

match /blobs/{hash}/{fileName} {
  allow read;
  allow write: if base64Encode(toBytes(hash, 16)) == request.resource.crc32c;
}

注意：toBytes(hash, 16)默认按大端字节序转换，和GCS/Firebase的CRC32C字节序一致。如果你的hash是小端字节序的十六进制，需要先用reverse()函数调整字节顺序后再编码。

场景2：路径中的hash就是Base64格式 #

如果你的hash参数本身就是和request.resource.crc32c一致的Base64字符串，那只需要确保上传时路径中的hash完全匹配服务器计算的crc32c值即可。你可以先上传一个测试文件，在GCS控制台查看它的crc32c元数据，用这个值作为路径中的hash来测试规则是否生效。

额外注意事项 #

• request.resource.crc32c是Firebase服务器计算的，不是客户端上传时提供的，所以规则的校验是基于真实文件内容的校验和，能有效防止文件内容被篡改。
• 如果你的hash是无符号整数格式，需要先把整数转换成十六进制字符串（用toString(hash, 16)），再按场景1的方法处理。

内容的提问来源于stack exchange，提问作者Samy Pessé