2016-10-06 18 views
0

write操作のために、&権限Firebaseで、その後はこのような状況に出くわしたルールを理解するためのいくつかの記事をつもりだった:

{ 
    "rules": { 
    "users": { 
     "$uid": { 
     ".write": "$uid === auth.uid" 
     } 
    } 
    } 
} 

は、私がユーザーのための$uidスタンドは、IDを押して、それが適用されることを理解した上で行ってきましたUsersノードに対して生成されたすべての動的IDに適用されます。

{ 
    "rules": { 
    "articles": { 
     "$article": { 
     "title": { 
        ".write": "auth != null", 
        ".validate": "newData.isString() && newData.val() != ''" 
     } 
     } 
    } 
    } 
} 

articlesノードのためのプッシュID用$articleスタンドが、その後$userされているはずもusersノードのIDを押した場合:

は、その後、他のこのルールがなかった見ました。ではない?ルールの設定時に、プッシュIDを宣言するための標準命名規則は、Firebaseが正しく解析/理解できるようにするものです。

最後に、auth.uidの略語は何ですか?

答えて

3

auth.uidで始まります。これは、認証されたユーザーのuidを表します。 次は、$ userと$ articleです。これらのワイルドカードのパスはプッシュIDだけでなく何でも構いません。詳細についてはthe docsをご覧ください。

最初の例では、$ uidはユーザーIDのワイルドカードです。そこにある

"users" : { 
    "Henk": {//Only Henk can write here 
    }, 
    "John": {//Only John can write here 
    } 
} 

ワイルドカードパスの命名について:書き込みルールにあなたはそれがこのようなもの(代わりに明確にするためのUIDのの名前を使用)となりますので、認証されたユーザーのみが自分の場所に書き込むことができることを確認します私が知る限り、いかなる慣習もない。私はそれが何であるか知っているので、個人的に私は説明的な名前を使用します。ユーザーのuidをパスとして使用する場合は常に$ uid、残りの場合はオブジェクトIDの$ objectIDのようにします。 (これらはプッシュで生成されてもよいし、何か自家製でもよい)

残りについては、すべてdocs about security rulesを読むのに時間がかかることをお勧めします。

+0

ここに戻って6ヶ月後に - Firebaseを再学習する:D。終わりにウルの説明とセキュリティルールのリンク - KICKASS :) – BeingSuman

関連する問題