Обработка авторизации на стороне клиента с помощью Firebase

Randy Burgess спросил: 28 марта 2018 в 03:21 в: javascript

Я строю клиент, который использует Firebase, SDK Firebase JavaScript, службу проверки Firebase и базу данных реального времени для сохранения.

После нескольких разных источников у меня есть часть аутентификации хорошо работаю, но я нахожу ограниченные возможности авторизации для того, что я считаю эффективным решением.

Что мне нужно > , это присоединить один ключ / значение в auth-запись пользователя, чтобы я мог выполнять как аутентификацию, так и авторизацию только с одним клиентским вызовом для брандмауэра Firebase.

  • Я читал о добавление пользовательских требований к записи об аутентификации Firebase, но я видел, как люди, использующие библиотеку Firebase Admin (backend), устанавливают токен и анализируют токен. Я пытаюсь не добавлять дополнительные вызовы через функции Firebase или пользовательский Express-сервер, если я могу ему помочь.

  • Добавление отдельной записи профиля пользователя в RTDB очень просто, и я могу хранить данные аутентификации там. Тем не менее, это всегда требует одновременного вызова для проверки подлинности и авторизации, что, опять же, кажется очень неэффективным и исключает безопасное автономное использование клиента (если роли изменяются в RTDB).

  • Также кажется неэффективным сделать клиентский вызов для аутентификации, а затем запустить обязательный второй клиентский вызов для получения данных авторизации от функции Firebase (или любой другой серверной службы), которая может реализовать библиотеку администратора Firebase.

Основной вопрос: существует ли способ с JavaScript для достижения цели установки / получения данных аутентификации и авторизации из службы проверки подлинности Firebase с помощью одного запроса на бэкэнд и обработки на клиент?


1 ответ

Есть решение
Frank van Puffelen ответил: 28 марта 2018 в 03:59

Вы дали два варианта идиоматических подходов для пользовательских ролей.

  • Если вы встраиваете роль в маркер пользователя как пользовательское утверждение, вы получите его. в запросе аутентификации. Поскольку это операция, которая повышает уровень разрешений, ее следует выполнять в доверенной среде, такой как сервер, которым вы управляете, облачные функции или (если достаточно редко) ваш компьютер-разработчик.

  • Если вы не хотите этого делать и хотите сохранить его в базе данных, вам потребуется дополнительный запрос. Затраты на этот вызов, как правило, не являются проблемой производительности.

Также возможна комбинация из двух: вручную определить исходный UID"системного администратора", а затем использовать его в правилах безопасности вашей базы данных, чтобы разрешить предоставлять дополнительные права другим пользователям. Но у этого также будут роли в базе данных.

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

Randy Burgess ответил: 28 марта 2018 в 04:16
If you embed the role into the user's token as a custom claim, you'll get it in the authentication request - Но как получить доступ к пользовательской заявке на стороне клиента? Я не вижу этого в какой-либо документации?
Randy Burgess ответил: 28 марта 2018 в 04:19
The overhead of that call is usually not a performance problem - я не столько обеспокоен производительностью, сколько обеспокоен затратами на использование (чтение) Firebase RTDB с течением времени и использованием клиента в автономном режиме.
Frank van Puffelen ответил: 28 марта 2018 в 04:39
Если вы уже используете базу данных в реальном времени, считывание role: 'admin' из этого требует минимальных затрат. Это звучит как преждевременная оптимизация для меня. Пользовательские утверждения должны быть доступны на клиенте, что было недавним изменением. См. Firebase.google.com/docs/auth/admin/…
Randy Burgess ответил: 28 марта 2018 в 04:50
Спасибо за ответы. Позвольте мне предоставить немного больше контекста, потому что вы предполагаете, что я создаю новое приложение с нуля, а это не так. Я пытаюсь перенести существующее приложение с использованием, и вопрос задается с обоснованными соображениями стоимости.
Frank van Puffelen ответил: 28 марта 2018 в 07:36
Размер "role": "admin" в JSON составляет 15 символов. Считывание из базы данных по цене 1 долл. США / ГБ сводится к 0,000000015 долл. США на пользователя или> 66 млн. Пользователей на 1 долл. США. Если это не входит в причину вашего варианта использования, вы можете сохранить данные в качестве пользовательской заявки в токене, где плата за пропускную способность не взимается.