Облачные функции Firebase Защищают конечные точки HTTPS с помощью ключа API - PullRequest
Новая
       39

Облачные функции Firebase Защищают конечные точки HTTPS с помощью ключа API

0 голосов
/ 20 октября 2018

Я смотрел в нескольких местах, включая эту запись и панель пожарной базы

enter image description here

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

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

Создание нового ключа API и использование , который в качестве параметра в моем запросе не работает(не сейчас, если я делаю что-то не так)

enter image description here

Есть ли способ сделать это?

Ответы [ 2 ]

0 голосов
/ 30 октября 2018

Вариант 1: обрабатывать аутентификацию в функции

https://github.com/firebase/functions-samples/tree/master/authorized-https-endpoint

Адаптировать выше для использования клиентов / ключей, хранящихся в firestore

Вариант 2. Использование API-шлюза

  • Конечные точки Google Cloud (пока нет прямой поддержки функций, необходимо реализовать прокси )
  • Apigee (более высокая стоимость, возможно, больше, чем нужно)
  • Управление Azure API (более низкая начальная стоимость + простота реализации какфасад служб, размещенных вне Azure)
  • есть еще ..

Вышеуказанные шлюзы, вероятно, лучше всего подходят для вашего случая использования, поскольку первые два позволят вам хранить все в GoogleХотя и с большей сложностью / стоимостью - надеюсь, конечные точки скоро получат поддержку функций.Azure будет означать, что часть вашей архитектуры находится за пределами Google, но выглядит как простой способ добиться того, что вам нужно (API-ключ для каждого клиента для ваших функций облака Google / Firebase)

Вот хорошее руководство по внедрению Azure API Management:

https://koukia.ca/a-microservices-implementation-journey-part-4-9c19a16385e9

0 голосов
/ 29 октября 2018

Не для достижения того, что вам нужно, поскольку Firebase и GCP обеспокоены тем, что ваши клиенты - ваша конкретная бизнес-проблема.

Один из способов решения этой проблемы (с небольшой предоставленной информацией);

  1. Вам нужно где-то хранить список клиентов + их ключ API (я быиспользуйте firestore)

  2. Для конечных точек, которые вы хотите защитить с помощью клиентского API-ключа, вы можете включить проверку, чтобы подтвердить, что заголовок существует, а также существует в вашей записи клиента firestore.

Соображения:

  1. В зависимости от ожидаемой загрузки трафика и количества операций чтения из хранилища, которые вы добавите, вы можете дважды проверить этот тип решения.будет работать за ваш бюджет.
  2. Является ли решение типа API-ключа единственным вариантом, на который вы должны пойти?Вы могли бы, вероятно, продвинуться далеко вперед, используя https://github.com/firebase/firebaseui-web и выполняя пользовательские проверки в вашей функции без необходимости дополнительного чтения БД.Если вы пойдете по этому пути, большая часть логики регистрации / электронной почты / создания учетной записи пользователя будет готова.https://firebase.google.com/docs/auth/web/password-auth#before_you_begin

Интересно посмотреть, что предлагают другие пользователи firebase.

...