У меня есть do c как это (все это упрощено) ...
myCollection -> myDoc: {
...
roles: { "xyz123" : "reader" } // associate UIDs with privileges
}
и такое правило ...
match /myCollection/{doc=**} {
allow list: if request.auth.uid != null;
allow read: if canRead(resource);
где canRead
определяется как ...
function canRead(res) {
return request.auth.uid != null &&
request.auth.uid in res.data.roles &&
res.data.roles[request.auth.uid] == 'reader';
}
Используя симулятор, имитируя аутентифицированного пользователя с UID = "abcdef" (отсутствует в объекте roles
), я вижу, что это правило предотвращает получение. Когда смоделированный UID = "xyz123" (который присутствует в roles
), получение разрешено.
Но в моем приложении при выполнении того же эксперимента чтение проходит успешно с UID, который не должен быть разрешен . Другими словами ...
console.log(firebase.auth().currentUser.uid) // logs 'abcdef', which should not be permitted
db.collection('myCollection').onSnapshot(snapshot => {
console.log(snapshot.docs) // logs several docs, including myDoc
Насколько я понимаю, снимок коллекции не должен быть разрешен, потому что один из результатов не может быть прочитан. Кроме того, возвращенные документы фактически содержат do c, которое следует исключить.
Можете ли вы представить себе обстоятельства, при которых обе эти вещи могут быть верными: смоделированное получение не выполняется, как и ожидалось, но реальное получение из клиент преуспевает, несмотря на запрещающее правило?