hashing 在规则游乐场中
我正在测试 hashing > “，“秘密”字符串的正确哈希：
let expected = hashing.sha256("SECRET");
但这是返回“ secretpath/to/to/file.mp4”，参数本身而不是其哈希：
let expected = hashing.sha256("SECRET" + request.resource.name);
它是规则游乐场中的错误吗？
可以在动态值上使用哈希功能吗？还是有意防止它？
奇怪的规则游乐场行为以前已经在这里提到过，这次使用了Firestore安全规则： firestore规则hashing hashhing hashing return返回身份
I am testing hashing in the rules playground:
This returns "CRexOpCRkV1UtjNvRZCVOczkUrNmGyHzhkGKJXiDswo=", the correct hash of the string "SECRET" :
let expected = hashing.sha256("SECRET");
But this returns "SECRETpath/to/the/file.mp4", the argument itself instead of its hash:
let expected = hashing.sha256("SECRET" + request.resource.name);
Is it a bug in the rules playground?
Can hashing functions be used on dynamic values or is it intentionally prevented?
The strange rules playground behavior has been mentioned here before, this time with Firestore security rules: Firestore rules hashing returns identity
发布评论
评论（2）
火灾者在这里！
这里有一些问题。我认为混淆的主要来源是
hashing。 sha256函数返回a类型。看来，在调试字节类型时，Firebase控制台中的规则游乐场错误地显示了字符串值，但这与生产中的行为无关。 例如，此规则将始终否认：要获得您要寻找的行为，您需要为
ulude.bytes使用其中一种转换功能类型。根据您的问题，您可能需要tobase64（tobase64（ ）函数，但是 也是一个选项。如果您在规则中尝试这些功能，则操场应该开始正确地行事，并且规则也将按预期工作。 为了将其全部结合在一起，您要写：例如，下面列出的规则允许您上传一个称为“ foo/bar”的文件（如
gqot1hkcledfq577770usfmkdkqxt_-jp4drktnmxl9m4drktnmxl9m4 = 是“ SecretFoo/bar”的base64 SHA-256哈希），希望这有助于清除一切！单独我们将考虑解决操场上错误的调试输出
Firebaser here!
There are a few issues at play here. I think the primary source of confusion is that the
hashing.sha256function returns arules.Bytestype. It appears that the Rules Playground in the Firebase Console incorrectly shows a string value when debugging the bytes type, but that is unrelated to behavior in production. For example, this Rule will always deny:To get the behavior you're looking for, you need to use one of the conversion functions for the
rules.Bytestype. Based on your question, you'll probably want thetoBase64()function, buttoHexString()is also an option. If you try these functions in your Rules, the Playground should start behaving correctly and the Rules will work as expected in production as well. So to put it all together, you'd write:For example, the rules listed below would allow you to upload a file called "foo/bar" (as
Gqot1HkcleDFQ5770UsfmKDKQxt_-Jp4DRkTNmXL9m4=is the Base64 SHA-256 hash of "SECRETfoo/bar")I hope this helps clear things up! Separately we will look into addressing the wrong debugging output in the Playground
在使用模拟器和已部署的应用程序尝试后，似乎Hashing.SHA256在任何环境中都不适用于动态数据。行为是一致的，因此我提交了功能请求将此功能添加到存储安全规则中。这是很好的，因为它将允许将签名的数据传递给每个文件的安全规则（对于Ex：通过云功能获得的上传授权）
到目前为止，我想象的解决方法正在将数据放入用户custom custom代币（或自定义）中索赔），因此我可以将签名的数据传递给安全规则。这不是理想的选择，因为我需要与每个文件上传重新签名。
After trying with emulators and the deployed app, it seems that hashing.sha256 does not work on dynamic data in any environment. The behavior is consistent, so I filed a feature request to add this function to storage security rules. This would be nice because it would allow passing signed data to the security rule for each file (for ex: an upload authorization obtained via a Cloud Function)
As of now, the workaround that I imagine is putting data in user custom token (or custom claims), so I can pass signed data to the security rule. It is not ideal because I need to re-sign with custom token for every file upload.