Триггеры Firebase Authentication

Вы можете запускать функции в ответ на создание и удаление аккаунтов пользователей Firebase Authentication. Например, вы можете отправить приветственное письмо пользователю, который только что создал аккаунт в вашем приложении. Примеры на этой странице основаны на образце, который делает именно это – отправляет приветственные и прощальные письма при создании и удалении аккаунта.

Дополнительные примеры использования приведены в статье Что можно делать с помощью Cloud Functions?.

Запуск функции при создании пользователя

Вы можете создать функцию, которая будет активироваться при создании пользователя Authentication, с помощью обработчика событий onUserCreated из подпакета firebase-functions/v2/identity:

const { onUserCreated } = require("firebase-functions/identity");
const { defineSecret } = require("firebase-functions/params");
const { logger } = require("firebase-functions");
const { sendWelcomeEmail } = require("./utils/myEmailService");

const emailApiKey = defineSecret("EMAIL_API_KEY");

exports.newUserWelcome = onUserCreated(
  { secrets: [emailApiKey] },
  async (event) => {
    const { uid, email, displayName } = event.data;

    if (!email) {
      logger.log(`User ${uid} does not have an email address.`);
      return;
    }

    await sendWelcomeEmail(email, displayName);
  },
);

Аккаунты Authentication будут активировать события создания пользователей для Cloud Functions, когда:

  • Пользователь создает аккаунт электронной почты и пароль.
  • Пользователь впервые входит в систему, используя интегрированного поставщика идентификационной информации.
  • Разработчик создает аккаунт с помощью Admin SDK.
  • Пользователь впервые входит в новый анонимный сеанс аутентификации.

Событие Cloud Functions не активируется, когда пользователь впервые входит в систему с помощью специального токена.

Как настроить триггеры и мультиарендность

Вы можете настроить функцию, передав объект options (AuthOptions) в качестве первого параметра в onUserCreated:

/**
 * Sends a welcome email scoped to a specific tenant in Identity Platform.
 */
exports.sendWelcomeEmailToTenant = onUserCreated(
  {
    secrets: [emailApiKey],
    // Only trigger when a user is a member of this tenant
    tenantId: "my-tenant-id",
  },
  async (event) => {
    const { uid, email, displayName } = event.data;
    // Customize the email for this tenant
    await sendWelcomeEmail(email, displayName, event.tenantId);
  },
);
  /**
 * Sends a welcome email only to users not associated with any tenant.
 */
exports.sendWelcomeEmailNoTenant = onUserCreated(
  {
    secrets: [emailApiKey],
    // Only trigger when a user is NOT a member of a tenant
    tenantId: IS_NOT_TENANT,
  },
  async (event) => {
    const { email, displayName } = event.data;

    // Send a generic welcome email
    await sendWelcomeEmail(email, displayName);
  },
);

Если в вашем проекте используется мультиарендность Identity Platform, вы можете ограничить область действия триггера:

  • Проект по умолчанию (без клиента). Задайте для tenantId значение IS_NOT_TENANT, чтобы прослушивать только пользователей, созданных в проекте по умолчанию.
  • Определенный клиент. Укажите строковый идентификатор клиента (например, { tenantId: "tenant-id-1" }), чтобы отслеживать только пользователей, созданных в этом клиенте.
  • Все клиенты и пользователи. Если tenantId не указан, функция активируется при создании пользователей во всех клиентах и проектах по умолчанию.

Помимо tenantId, вы можете указать стандартные параметры конфигурации второго поколения, включая region, concurrency, cpu, memory, timeoutSeconds, minInstances, maxInstances и secrets.

Как получить доступ к атрибутам пользователей

Из пользовательских данных, возвращенных в функцию, вы можете получить доступ к списку атрибутов пользователя, доступных в объекте UserRecord только что созданного пользователя, через event.data. Например, вы можете получить адрес электронной почты и отображаемое имя пользователя, как показано ниже:

const { uid, email, displayName } = event.data;

Триггеры аутентификации второго поколения получают объект AuthEvent. Помимо event.data, вы можете получить доступ к метаданным событий, таким как:

  • event.id: уникальный идентификатор события.
  • event.type – тип события (google.firebase.auth.user.v2.created).
  • event.time – временная метка в формате ISO 8601, указывающая, когда произошло событие.
  • event.project – идентификатор проекта Google Cloud.
  • event.tenantId – идентификатор клиента Identity Platform, связанный с пользователем (если применимо).

Как запустить функцию при удалении пользователя

Вы можете настроить запуск функции не только при создании, но и при удалении пользователя. Используйте обработчик событий onUserDeleted из firebase-functions/v2/identity, как показано ниже.

const { onUserDeleted } = require("firebase-functions/identity");
const { defineSecret } = require("firebase-functions/params");
const { logger } = require("firebase-functions");
const { sendGoodbyeEmail } = require("./utils/myEmailService");

const emailApiKey = defineSecret("EMAIL_API_KEY");

exports.deletedUserFarewell = onUserDeleted(
  { secrets: [emailApiKey] },
  async (event) => {
    const { uid, email, displayName } = event.data;
    if (!email) {
      logger.log(`User ${uid} does not have an email address.`);
      return;
    }

    await sendGoodbyeEmail(email, displayName);
  },
);

Как и в случае с onUserCreated, вы можете настроить onUserDeleted с помощью таких параметров, как { tenantId: IS_NOT_TENANT }, чтобы ограничить триггеры пользователями в проекте по умолчанию.

Как активировать блокирующие функции

Если вы перешли на Firebase Authentication with Identity Platform, то можете расширить Firebase Authentication с помощью функций блокировки.

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

Рекомендации по работе с триггерами второго поколения

При реализации триггеров аутентификации второго поколения учитывайте следующие рекомендации:

  • Учитывайте параллельные запросы. Экземпляры Cloud Functions (второго поколения) обрабатывают параллельные запросы (по умолчанию 80 параллельных запросов, если ЦП ≥ 1). Убедитесь, что ваша функция не зависит от глобального изменяемого состояния между параллельными выполнениями.
  • Проектирование для идемпотентности. Доставка событий во втором поколении осуществляется как минимум один раз через Eventarc. Убедитесь, что ваши функции идемпотентны. Например, проверьте, что приветственное письмо ещё не отправлено или запись в базе данных не инициализирована, прежде чем выполнять побочные эффекты.
  • Определите область действия функций для нескольких клиентов. Если в вашем приложении используется многоклиентская архитектура Identity Platform, проверьте, должны ли функции обрабатывать события для всех клиентов или только для определенных. Используйте tenantId: IS_NOT_TENANT, чтобы пользователи клиента не могли запускать функции, предназначенные только для основного проекта.
  • Управление регионами и распределением ресурсов. Укажите местоположение функции (region), чтобы минимизировать задержку сети между поставщиком аутентификации и средой выполнения функции.