Доступ пользователей Firebase/Firestore и роли, как это работает?

# #firebase #google-cloud-firestore #firebase-authentication

Вопрос:

Я пытаюсь понять, как система ролей работает с Firebase, но я крайне сбит с толку и не понимаю, как все это работает.

Я думаю, что понял, что для предоставления роли пользователю необходимо использовать либо SDK администратора Firebase, либо правила безопасности в Firestore.

Однако я не понимаю разницы и почему одно было бы более эффективным, чем другое, и как это работает.

Например:

У меня есть приложение для доставки только с 2 ролями: доставщик и администратор

У доставщиков есть мобильное приложение, которое указывает адрес, по которому должна быть доставлена посылка.

Администратор имеет доступ к тому же интерфейсу, что и доставщик в мобильном приложении, но имеет доступ к веб-приложению для управления доставкой. Он может добавить доставку, водителя и т. Д…

Как работает проверка подлинности Firebase и как правильно использовать назначение ролей?

Нужно ли звонить в базу данных «пользователь», чтобы узнать, является ли он администратором или обычным пользователем, как только он войдет в систему ?

Ответ №1:

Ответ на этот вопрос немного велик, поэтому я не могу предоставить для него фрагменты кода. Но я могу указать на пример проекта, в котором есть «атомарная» ролевая система. Вы можете проверить это здесь.

Основы. Вы можете сохранить роли пользователя в базах данных (RTDB или Firestore). Если вам нужны обе базы данных, синхронизируйте их между обеими, чтобы иметь единую систему.

Главное, что каждый пользователь может читать только свои собственные роли и только в том случае, если он администратор. Изменения в этих данных должны выполняться только с использованием облачных функций firebase. Чтобы проверить, является ли пользователь администратором или имеет роль, выполните простую проверку «существует» для аутентифицированного пользователя и существует ли для него соответствующая роль или статус администратора.

В firestore у вас даже могут быть вспомогательные функции, подобные этим здесь:

 
    //Checks if user is signed in
    function isSignedIn() {
      return request.auth.uid != null;
    }

    //Checks if user has admin rights
    function isAdmin() {
      return exists(/databases/$(database)/documents/admins/$(request.auth.uid))
    }

    //Checks if user has a specific grant
    function hasGrant(grant) {
      return  get(/databases/$(database)/documents/user_grants/$(request.auth.uid)).data[grant]==true
    }

    //Checks if user is granted either as admin or with a grant
    function isGranted(grant){
      return isAdmin() || hasGrant(grant);
    }


    //Checks if user has specific UID
    function isOwner(userUid){
      return request.auth.uid == userUid 
    }
 

Некоторые сказали бы, что нужно использовать customClaims , но я бы никогда не рекомендовал этого. Может быть, только для статуса администратора и не более того. Они имеют небольшой размер, чтобы иметь на них систему ролей большего размера. Сохраняя роли в базах данных, вы можете изменять их даже в режиме реального времени.

Чтобы получить роли и статус администратора для пользователя, просто создайте прослушиватель в реальном времени для этих данных.