Правила Firestore с мультитенантностью? - PullRequest
1 голос
/ 06 августа 2020

Документы Firebase Rules предлагают условия построения, сравнивающие токен аутентифицированного пользователя (например, request.auth) с целевым документом (-ами) Firestore. Что-то вроде:

match /posts/{postId} {
  allow read, write: if (request.auth.uid != null) && 
    (resource.data.tenantId == request.auth.token.tenantId);
}

Однако tenantId, похоже, недоступен в Правилах Firebase , как и другие связанные поля аутентификации (например, uid, email, email_verified, и т.д. c.).

Один из вариантов, по-видимому, состоит в том, чтобы добавить tenantId отдельно как настраиваемое утверждение с использованием firebase-admin SDK. Но это приведет к дублированию информации об объекте пользователя:

{
  uid: 'nzjNp3QIfSR6uWy',
  emailVerified: true,
  displayName: 'pickleR'
  ...
  tenantId: 'wubalubadubdub',
  customClaims: { tenantId: 'wubalubadubdub' },
}

Альтернативный вариант , по-видимому, заключается в создании коллекции tenants в Firestore. Однако такой подход, похоже, вносит ненужную сложность и увеличивает количество требуемых запросов к Firestore.

Существуют ли альтернативы для доступа к tenantId в правилах Firestore и / или альтернативные передовые практики использования Firestore с несколькими -наемность?

1 Ответ

1 голос
/ 06 августа 2020

Два варианта, которые вы описываете, являются идиоматическими c:

  1. Передайте информацию в правила как часть идентификационного токена в качестве настраиваемого утверждения.
  2. Посмотрите вверх информация в базе данных из правил request.auth.uid.

Ни один из них не всегда лучше другого: пользовательские утверждения более удобны и читабельны, а использование базы данных обычно быстрее. Обычно поиск в базе данных используется для получения более изменчивой информации и требований для информации, которая является «однажды».

Поскольку это для идентификатора клиента, который вряд ли изменится быстро, я бы, вероятно, go для индивидуальной претензии.

...