Цель состоит в том, чтобы пользователи с правами администратора
Поскольку вы используете службу Аутентификация , у вас уже есть половина решения: с аутентификацией вы можете идентифицировать каждый пользователь, который использует ваше приложение.
Другая часть - Авторизация : обычно это делается с помощью правил безопасности в Firebase, как для Firestore, так и для облачного хранилища.
Чтобы иметь возможность авторизовать определенных пользователей (идентифицированных с помощью аутентификация ) с правами администратора, вам необходимо знать, какие пользователи имеют роль администратора таким образом, который вы авторизовали их выполнять функции администратора.
Один из возможных способов идентификации пользователей-администраторов - пометить isAdmin в некоторых пользовательских документах в Firestore, как вы упомянули в своем вопросе. Существует пример правила безопасности Firestore, использующего этот подход в документации .
HOWEVER , вы столкнетесь с некоторой проблемой, если захотите использовать этот флаг (хранится в Firestore) с правилами безопасности для облачного хранилища. На момент написания невозможно прочитать значение документа Firestore в Правилах безопасности для облачного хранилища.
Решение состоит в том, чтобы использовать Пользовательские утверждения . В документации do c вы найдете все подробности о том, как реализовать ее таким образом, чтобы она отвечала вашим потребностям.
Можно ли создать панель администратора внутри клиентского приложения?
Да, вы очень хорошо можете это сделать. Как только ваша безопасность будет правильно реализована (с помощью правил аутентификации и безопасности, как описано выше), ничто не помешает вам создать панель администратора. Если пользователь, не являющийся администратором, может получить доступ к панели администратора, он / она не сможет выполнять действия администратора (например, запись / редактирование / удаление данных Firestore или Cloud Storage).
Более того, с пользовательскими утверждениями Вы можете получить к ним доступ во внешнем интерфейсе, чтобы изменить пользовательский интерфейс клиента в зависимости от роли пользователя или уровня доступа (т. е. показывать страницы, кнопки и пункты меню модуля Admin только для пользователей-администраторов), однако следует помнить, что это не мешает кому-либо провести обратный инжиниринг своего приложения и выполнить запросы, предназначенные для пользователей-администраторов: вот почему важно правильно реализовать части «Правила аутентификации и безопасности» -). См. Этот раздел в разделе Пользовательские утверждения: c.
Должен ли я создать панель администратора в другом приложении и использовать облачные функции?
Если вы не хотите чрезмерно усложнять свое приложение с помощью некоторой логики c, чтобы скрыть / показать элементы панели администратора (на основе пользовательских утверждений, см. Выше), вы можете очень хорошо построить панель администратора в другом приложении.
Если у вас есть определенные c потребности / ограничения доступа, которые не могут быть реализованы с помощью стандартных правил безопасности, вы вполне можете использовать некоторые облачные функции, чтобы проверить, является ли пользователь администратором, и выполнить написание / редактирование / удаление действий администратора (примечание однако, несмотря на то, что взаимодействие с Firestore из облачной функции довольно просто, с хранилищем это может быть немного сложнее: использовать клиентские SDK облачного хранилища гораздо проще, чем взаимодействовать с облачным хранилищем через облачные функции).
Желательно использовать Callable Cloud Functions, поскольку «с вызываемыми, Firebase Authentication и токенами FCM, если они доступны, автоматически включаются в запросы». (См. https://firebase.google.com/docs/functions/callable).
Примечание: Вас может заинтересовать эта статья , в которой подробно описано, как создать модуль администратора для управления доступ пользователей и роли. (Отказ от ответственности: я автор).