Firebase не знает, что такое «Администратор» здесь. Это концепция, которая задает c для вашего приложения, поэтому вам придется применять ее.
Невозможно разрешить определенным пользователям входить в систему только на указанной c платформе. Это связано с тем, что Firebase четко разделяет аутентификацию (пользователь подтверждает, кто они) и авторизацию (пользователь имеет доступ к ресурсу). Вы используете Firebase Authentication для аутентификации пользователей, но у «кто может использовать какое приложение» возникает проблема с авторизацией, поэтому она решается в другом месте.
Если вы используете базу данных реального времени, облачное хранилище пожаров или облачное хранилище например, через Firebase вы, как правило, применяете нашу логику авторизации c в правилах Firebase на стороне сервера . Поскольку они автоматически применяются на сервере, пользователь не может их обойти, и они применяются одинаково независимо от того, на какой платформе он находится.
Например, общее первое правило безопасности, которое Я начинаю свои проекты Firestore с:
service cloud.firestore {
match /databases/{database}/documents {
match /chat/{document} {
allow read;
allow write:
if isAdmin()
}
function isAdmin() {
return false;
}
}
}
Это позволяет любому читать данные, а никто не записывать их, поскольку isAdmin всегда возвращает false. С этими правилами единственный способ записать данные - использовать Admin SDK, поскольку код, использующий этот SDK, выполняется с повышенными привилегиями и обходит правила безопасности. Идеальный способ начать и безопасно заполнить мою базу данных начальными данными из Node.js скриптов (в моем наиболее распространенном случае).
Затем в какой-то момент я делаю, как вы, и добавляю администратор приложения. В этот момент я добавляю их UID к правилам безопасности:
function isAdmin() {
return request.auth.uid == "KqEizsqUQ6XMkUgLUpNxFnzLm4F3"
|| request.auth.uid == "zYXmog8ySOVRrSGVt9FHFr4wJb92";
}
Таким образом, вышеприведенная функция в моих правилах теперь дает двум конкретным c пользователям аутентификации Firebase доступ к данным для записи.
Этот подход хорошо работает для первых нескольких пользователей, но в какой-то момент добавление UID в правила становится утомительным и подверженным ошибкам. На этом этапе у меня есть два основных варианта:
- Хранить UID администраторов приложений в базе данных.
- Идентифицировать администраторов приложений другим способом.
Для хранения UID в базе данных вы обычно либо добавляете эти UID в базу данных вручную, либо позволяете администраторам идентифицировать других администраторов и записывать их UID из приложения. В любом случае, правила безопасности для этого примерно такие:
function isAdmin() {
return request.auth.uid == "KqEizsqUQ6XMkUgLUpNxFnzLm4F3"
|| request.auth.uid == "zYXmog8ySOVRrSGVt9FHFr4wJb92"
|| exists(/databases/$(database)/documents/admins/$(request.auth.uid))
;
}
Таким образом, последняя строка теперь также распознает любого пользователя аутентификации, чей UID хранится в коллекции admins, в качестве администратора приложения.
Наконец, скажите, что я хочу, чтобы все в моей компании были администраторами приложений; Я бы сделал это с:
function isAdmin() {
return request.auth.uid == "KqEizsqUQ6XMkUgLUpNxFnzLm4F3"
|| request.auth.uid == "zYXmog8ySOVRrSGVt9FHFr4wJb92"
|| (request.auth.token.email_verified && request.auth.token.email.matches(".*@google.com"))
|| exists(/databases/$(database)/documents/admins/$(request.auth.uid))
;
}
Так что это означает, что любой пользователь аутентификации Firebase, имеющий подтвержденный адрес электронной почты @ google.com, теперь также является администратором приложения.
Как видите, я строю эти правила в несколько этапов, начиная с простого определения того, что у меня будут администраторы приложений с указанными правами доступа c, и создания функции isAdmin.