Конфликт пользователей при использовании одного и того же метода аутентификации для администраторов и обычных пользователей | Firebase Auth - PullRequest
1 голос
/ 28 февраля 2020

Я работаю над модулем администратора приложения android. Модуль администратора - это веб-приложение на основе Angular. Firebase auth (электронная почта / пароль) используется для входа в систему в качестве администратора. Я добавил учетную запись вручную в firebase, и администратор использует эти учетные данные для входа в систему (поскольку у администратора нет функции регистрации)

с другой стороны Android разработчик также использовал тот же метод аутентификации для подписи у пользователя. Таким образом, пользователи приложения android могут войти со своими учетными данными в модуль администратора.

Как запретить пользователям android вход в веб-приложение. Есть ли какой-либо метод или правило, которое я могу использовать для фильтрации входящего запроса на вход в систему и разрешения входа в систему, только если электронная почта принадлежит администратору?

1 Ответ

3 голосов
/ 28 февраля 2020

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 в правила становится утомительным и подверженным ошибкам. На этом этапе у меня есть два основных варианта:

  1. Хранить UID администраторов приложений в базе данных.
  2. Идентифицировать администраторов приложений другим способом.

Для хранения 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.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...