私はFirebaseを使用して作成しているiOSアプリケーションで、各ユーザーは電子メールとパスワードでサインアップした後に作成される固有のユーザー名を持っています。&&と||を持つこのFirebaseデータベースセキュリティルールはなぜですか? not working
ので[email protected]の電子メールを持つユーザーがサインアップし、その後、次のようにデータベースのスニペットは次のようになり、ユーザ名データベースにないユニークなユーザ名を作成するために持っていた場合:
"usernames" : {
"test" : "r6KPesUr1qORfIJke07SloZHeNW2",
"test1" : "jSMSkY9rHtdNkXoLrsFmCAXdY9n2",
"test7" : "jnFhJbgCjZeJFx0hspObqoskQej2",
"test8" : "HtnULzU0lnZKYva2M2Wepl6N8wE3"
},
"users" : {
"HtnULzU0lnZKYva2M2Wepl6N8wE3" : {
"email" : "[email protected]",
"username" : "test8"
},
"boX6rtJ98haWVxNoXfSq21maCVU2" : {
"email" : "[email protected]"
},
"jSMSkY9rHtdNkXoLrsFmCAXdY9n2" : {
"email" : "[email protected]",
"username" : "test1"
},
"jnFhJbgCjZeJFx0hspObqoskQej2" : {
"email" : "[email protected]",
"username" : "test7"
},
"r6KPesUr1qORfIJke07SloZHeNW2" : {
"email" : "[email protected]",
"username" : "test"
}
}
を
私は、ユーザーがサインアップを完了したときにユーザー名が一意であることを確認するために、次のセキュリティ規則を用意しています。検証ルールについては
// USERNAMES
"usernames": {
".read": "auth.uid != null",
".write": "auth.uid != null",
"$username": {
".validate": "(!root.child('usernames').hasChild($username.toLowerCase()) && newData.val() == auth.uid &&
root.child('users').hasChild(auth.uid)) &&
(root.child('users/'+auth.uid+'/username').val().toLowerCase() == $username ||
!root.child('users/'+auth.uid+'/username').exists())"
}
}
(!root.child('usernames').hasChild($username.toLowerCase()) &&
newData.val() == auth.uid &&
root.child('users').hasChild(auth.uid))
これら二つの文でそれらのいずれかに該当
"(root.child('users/'+auth.uid+'/username').val().toLowerCase() == $username ||
(!root.child('users/'+auth.uid+'/username').exists()"
もしそうならなければならないがぐるぐるしなければならないと私は、これらの3つの文を持っていると思いますユーザーはtest5にサインアップしたかったので、次のjsonにユーザー名を入力すると、最初の部分のために現在のセキュリティールールでは機能しませんORステートメント。
"users": {
"boX6rtJ98haWVxNoXfSq21maCVU2": {
"username": "test5"
}
}
私は間違っていますか?
ルールを解析するのは非常に難しいです。この検証ルールで拒否される最小限のコードを含めるように質問を編集できますか? –
@FrankvanPuffelen確かに。私は、データベースがどのように見えるのか、そしてその後[email protected] – Edward
のメールでユーザの一意のユーザ名を作成するために書かれていないjsonを追加しました。あなたのユースケースを理解しようとしました。しかし、このような複雑なルールから理解するのは難しいので、私は1つ(よく2つ)の特定のユースケースを分離し、それに焦点を当てました。 –