1

何が起こっているのかというと、通常、セッションが期限切れになるのに十分な時間が経過した後に初めてユーザーを認証すると、ユーザーがアクセスできるはずのデータに対する要求が拒否されます。リクエストは、実際のルールやコードを変更することなく、最終的に機能し始めます。2 ～ 10 分かかる場合がありますが、最終的には自然に回復します。

これに関する確固たるデータはありません。それは私が観察したことです。

これについて何ができるかわかりません。他の誰かがこれを見ていますか？これは既知のバグですか? 検索しましたが、これが起こっているという他のアカウントは見つかりませんでした。

ありがとう。

ルールは次のとおりです。

{
 "rules": {

    "users": {
      "$user": {
        ".read" :"$user == auth.id || data.child('email').val() == auth.email",
        ".write":"$user == auth.id"
      }
    },

    "todos":{
      "$list":{
        ".read":"data.child('members').hasChild(auth.id)",
        ".write":"newData.child('members').hasChild(auth.id)"
      }
    }
  }
}
4

1 に答える 1

0

デフォルトでは、認証トークンは 24 時間存続するため、それ以前にセキュリティ エラーが表示される場合は、おそらくセッションとは関係ありません。これを確認するには、コールバックをアタッチして、セッションの有効期限が切れたことを通知します。参照: https://www.firebase.com/docs/javascript/firebase/auth.html

ここで起こっていることは、単純に、ルールが依存しているデータが変更され、書き込みが成功したり失敗したりすることがあるということだと思います。これは、Firebase のセキュリティ ルールの意図された動作です。たとえば、誰かが /todos/blah/members/ に追加/削除された場合、/todos/blah で読む能力に影響します

あなたのルールの奇妙な点の 1 つは、書き込むデータにライターのユーザー ID を含むメンバー リストが含まれている限り、誰でも /todos/$list に書き込むことを許可しているように見えることです。これはあなたの意図した動作ではないと思います。おそらく、新しいデータではなく、Firebase に既に存在するデータに基づいて書き込みルールを作成するつもりでしたか?

于 2013-03-22T19:13:12.747 に答える