Firebase: установить правила безопасности в зависимости от ролей пользователя

Question

Я хотел бы реализовать правила безопасности «write» в Firebase в зависимости от ролей пользователей.
Моя структура данных, как это:

+ myapp 
    + users 
    + john 
     + email: "john@mail.com" 
     + roles 
     + administrator: true 
    + mary 
     + email: "mary@mail.com" 
     + roles 
     + moderator: true 
    + ... 
    + documents 
    + -JVmo6wZM35ZQr0K9tJu 
     + ... 
    + -JVr56hVTZxlAI5AgUaS 
     + ... 
    + ... 

Я хочу - например - что только пользователи администратор может создавать документы.
Эти правила я пришел:

{ 
    "rules": { 
    ".read": true, 
    "$documents": { 
     ".write": "root.child('users').child(auth.uid).child('roles').child('administrator').val() === true" 
    } 
    } 
} 

Но это не работает: даже не пользователи администратор может создавать документы ...
ли мое понимание Firebase правил безопасности полностью испорчено?

UPDATE: Как раз перед ответом Дженни (верить или нет :-), я осуществить точно такое же решение, он обеспечивает (конечно основанный на комментарий Като).
Хотя, делая некоторые тесты, я не мог позволить структуре правил,

{ 
    "rules": { 
    "documents" { 
     "$document" { 
     ".read": "root.child('users').child(auth.uid).child('roles').child('documents').child('read').val() === true", 
     ".write": "root.child('users').child(auth.uid).child('roles').child('documents').child('write').val() === true" 
     } 
    } 
    } 
} 

работы ... Я всегда получал предупреждение, как это:

"FIREBASE WARNING: on() or once() for /documents failed: Error: permission_denied: Client doesn't have permission to access the desired data. " 

Так что я пришел с этой структурой, а :

{ 
    "rules": { 
    "documents" { 
     ".read": "root.child('users').child(auth.uid).child('roles').child('documents').child('read').val() === true", 
     ".write": "root.child('users').child(auth.uid).child('roles').child('documents').child('write').val() === true" 
    } 
    } 
} 

Который действительно работает для меня: если я устанавливаю ролей/клиент/чтение узла истинен на пользователе он может читать все документы, в противном случае он не может (и то же самое для ш Обряд).

Мои сомнения сейчас:

• почему я не мог позволить первое правило (как это было предложено Като) работать?
• Вы видите любое возможное отверстие безопасности в правиле, подобное тому, которое я сделал?
:
• - это правила с использованием переменных «$», необходимых/полезных, даже если вам не нужно разрешать/запрещать чтение/запись каждого документа на основе его ключа, но вы просто хотите разрешить/запретить чтение/отказ читабельности/способность записывать узел в целом?

Answer 1

на основе имен ваших записей пользователей, они не совпадают auth.uid, что, вероятно, Simple Login идентификатор, например twitter:2544215.

Start, корректируя пользователям хранить их Simple Login UID:

+ myapp 
    + users 
    + twitter:2544215 
     + email: "john@mail.com" 
     + roles 
     + administrator: true 
    + twitter:2544216 
     + email: "mary@mail.com" 
     + roles 
     + moderator: true 
    + ... 
    + documents 
    + -JVmo6wZM35ZQr0K9tJu 
     + ... 
    + -JVr56hVTZxlAI5AgUaS 
     + ... 
    + ... 

Далее добавьте правила безопасности, так что администраторы могут получить доступ к documents. У вас есть пара вариантов здесь, в зависимости от вашего конкретного варианта использования.

1. Чтобы дать администраторам доступ на запись к содержанию каждого документа:

   { 
       "rules": { 
       "documents": { 
        "$documents": { 
        ".write": "root.child('users').child(auth.uid).child('roles').child('administrator').val() === true" 
        } 
       } 
       } 
   } 
   

2. Или, наоборот, дать им доступ ко всей коллекции:

   { 
       "rules": { 
       "documents": { 
        ".write": "root.child('users').child(auth.uid).child('roles').child('administrator').val() === true" 
       } 
       } 
   } 
   

Разница между этими двумя является переменная $documents, которая перемещает правило безопасности на один шаг дальше в иерархию.

(Это было в основном только агрегация комментариев @Kato в форму ответа)