Secure Data Connect с авторизацией и аттестацией

Firebase Data Connect обеспечивает надежную безопасность на стороне клиента благодаря следующим функциям:

• Авторизация мобильных и веб-клиентов
• Индивидуальные средства управления авторизацией на уровне запросов и изменений
• Аттестация приложений с помощью Firebase App Check .

Data Connect расширяет эту безопасность за счет следующих функций:

• Авторизация на стороне сервера
• Безопасность пользователей Firebase и Cloud SQL с помощью IAM.

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

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

Data Connect предоставляет директиву @auth для запросов и мутаций, которая позволяет установить уровень аутентификации, необходимый для авторизации операции. В этом руководстве представлено описание директивы @auth с примерами .

Кроме того, Data Connect поддерживает выполнение запросов, встроенных в мутации, поэтому вы можете получить дополнительные критерии авторизации, которые вы сохранили в своей базе данных, и использовать эти критерии в директивах @check , чтобы решить, авторизованы ли содержащиеся в них мутации. В этом случае авторизации директива @redact позволяет вам контролировать, возвращаются ли результаты запроса клиентам по протоколу передачи, а встроенный запрос опускается в сгенерированных SDK. Введение в эти директивы с примерами можно найти здесь.

Разберитесь в директиве @auth

Вы можете параметризовать директиву @auth , чтобы она соответствовала одному из нескольких предустановленных уровней доступа, охватывающих множество распространенных сценариев доступа. Эти уровни варьируются от PUBLIC (разрешает запросы и изменения данных от всех клиентов без какой-либо аутентификации) до NO_ACCESS (запрещает запросы и изменения данных за пределами привилегированных серверных сред с использованием Firebase Admin SDK ). Каждый из этих уровней связан с потоками аутентификации, предоставляемыми Firebase Authentication .

Используя эти предустановленные уровни доступа в качестве отправной точки, вы можете определить сложные и надежные проверки авторизации в директиве @auth , используя фильтры where и выражения Common Expression Language (CEL), оцениваемые на сервере.

Используйте директиву @auth для реализации распространенных сценариев авторизации.

Заданные уровни доступа являются отправной точкой для авторизации.

Уровень доступа USER — это наиболее полезный базовый уровень, с которого можно начать.

Полностью защищенный доступ будет основан на уровне USER , а также на фильтрах и выражениях, проверяющих атрибуты пользователя, атрибуты ресурсов, роли и другие параметры. Уровни USER_ANON и USER_EMAIL_VERIFIED являются вариантами уровня USER .

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

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

В этом руководстве теперь приведены примеры того, как создавать приложения на основе USER и PUBLIC .

Показательный пример

Приведенные ниже примеры передовой практики относятся к следующей схеме для платформы ведения блогов, где определенный контент доступен только по платному тарифному плану.

Подобная платформа, скорее всего, будет моделировать Users и Posts .

type User @table(key: "uid") {
  uid: String!
  name: String
  birthday: Date
  createdAt: Timestamp! @default(expr: "request.time")
}

type Post @table {
  author: User!
  text: String!
  # "one of 'draft', 'public', or 'pro'"
  visibility: String! @default(value: "draft")
  # "the time at which the post should be considered published. defaults to
  # immediately"
  publishedAt: Timestamp! @default(expr: "request.time")
  createdAt: Timestamp! @default(expr: "request.time")
  updatedAt: Timestamp! @default(expr: "request.time")
}

Ресурсы, принадлежащие пользователям

Firebase рекомендует писать фильтры и выражения, проверяющие принадлежность ресурса пользователю, в следующих случаях — принадлежность объекта Posts .

В следующих примерах данные из токенов аутентификации считываются и сравниваются с помощью выражений. Типичный шаблон — использование выражений типа where: {authorUid: {eq_expr: "auth.uid"}} для сравнения сохраненного authorUid с auth.uid (идентификатором пользователя), переданным в токене аутентификации.

Создавать

Данная процедура авторизации начинается с добавления значения auth.uid из токена авторизации к каждой новой Post в качестве поля authorUid , что позволяет сравнивать данные в последующих проверках авторизации.

# Create a new post as the current user
mutation CreatePost($text: String!, $visibility: String) @auth(level: USER) {
  post_insert(data: {
    # set the author's uid to the current user uid
    authorUid_expr: "auth.uid"
    text: $text
    visibility: $visibility
  })
}

Обновлять

Когда клиент пытается обновить Post , вы можете проверить переданный auth.uid на соответствие сохраненному authorUid .

# Update one of the current user's posts
mutation UpdatePost($id: UUID!, $text: String, $visibility: String) @auth(level:USER) {
  post_update(
    # only update posts whose author is the current user
    first: { where: {
      id: {eq: $id}
      authorUid: {eq_expr: "auth.uid"}
    }}
    data: {
      text: $text
      visibility: $visibility
      # insert the current server time for updatedAt
      updatedAt_expr: "request.time"
    }
  )
}

Удалить

Аналогичный метод используется для авторизации операций удаления.

# Delete one of the current user's posts
mutation DeletePost($id: UUID!) @auth(level: USER) {
  post_delete(
    # only delete posts whose author is the current user
    first: { where: {
      id: {eq: $id}
      authorUid: {eq_expr: "auth.uid"}
    }}
  )
}

# Common display information for a post
fragment DisplayPost on Post {
  id, text, createdAt, updatedAt
  author { uid, name }
}

Список

# List all posts belonging to the current user
query ListMyPosts @auth(level: USER) {
  posts(where: {
    userUid: {eq_expr: "auth.uid"}
  }) {
    # See the fragment above
    ...DisplayPost
    # also show visibility since it is user-controlled
    visibility
  }
}

Получать

# Get a post only if it belongs to the current user
query GetMyPost($id: UUID!) @auth(level: USER) {
  post(key: {id: $id},
    first: {where: {
      id: {eq: $id}
      authorUid: {eq_expr: "auth.uid"}}
      }}, {
      # See the fragment above
      ...DisplayPost
      # also show visibility since it is user-controlled
      visibility
  }
}

Фильтрация данных

Система авторизации Data Connect позволяет создавать сложные фильтры в сочетании с предустановленными уровнями доступа, такими как PUBLIC , а также использовать данные из токенов авторизации.

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

Фильтрация по атрибутам ресурса

В данном случае авторизация не основана на токенах аутентификации, поскольку базовый уровень безопасности установлен на PUBLIC . Однако мы можем явно указать в нашей базе данных, что доступ к ней разрешен для всех пользователей; предположим, у нас есть записи Post в базе данных с уровнем visibility "public".

# List all posts marked as 'public' visibility
query ListPublicPosts @auth(level: PUBLIC) {
  posts(where: {
    # Test that visibility is "public"
    visibility: {eq: "public"}
    # Only display articles that are already published
    publishedAt: {lt_expr: "request.time"}
  }) {
    # see the fragment above
    ...DisplayPost
  }
}

Фильтрация по утверждениям пользователей

Предположим, вы настроили пользовательские утверждения, которые передают токены аутентификации для идентификации пользователей, использующих тарифный план «Pro» для вашего приложения, помеченный полем auth.token.plan в токене аутентификации. Ваши выражения могут проверять это поле.

# List all public or pro posts, only permitted if user has "pro" plan claim
query ProListPosts @auth(expr: "auth.token.plan == 'pro'") {
  posts(where: {
    # display both public posts and "pro" posts
    visibility: {in: ['public', 'pro']},
    # only display articles that are already published
    publishedAt: {lt_expr: "request.time"},
  }) {
    # see the fragment above
    ...DisplayPost
    # show visibility so pro users can see which posts are pro\
    visibility
  }
}

Фильтрация по порядку + лимиту

Или, например, вы могли установить visibility записей в Post таким образом, чтобы они соответствовали контенту, доступному для пользователей с платными правами, но для предварительного просмотра или ознакомительного списка данных можно дополнительно ограничить количество возвращаемых записей.

# Show 2 oldest Pro post as a preview
query ProTeaser @auth(level: USER) {
  posts(
    where: {
      # show only pro posts
      visibility: {eq: "pro"}
      # that have already been published more than 30 days ago
      publishedAt: {lt_time: {now: true, sub: {days: 30}}}
    },
    # order by publish time
    orderBy: [{publishedAt: DESC}],
    # only return two posts
    limit: 2
  ) {
    # See the fragment above
    ...DisplayPost
  }
}

Фильтр по роли

Если в вашем пользовательском запросе определена роль admin , вы можете соответствующим образом тестировать и авторизовывать операции.

# List all posts unconditionally iff the current user has an admin claim
query AdminListPosts @auth(expr: "auth.token.admin == true") {
  posts { ...DisplayPost }
}

Добавьте директивы @check и @redact для поиска данных авторизации.

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

Используя поиск данных авторизации, вы можете запрашивать роли на основе идентификатора пользователя и использовать выражения CEL для определения того, разрешена ли мутация. Например, вы можете написать мутацию UpdateMovieTitle , которая позволит авторизованному клиенту обновлять названия фильмов.

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

# MoviePermission
# Suppose a user has an authorization role with respect to records in the Movie table
type MoviePermission @table(key: ["movie", "user"]) {
  movie: Movie! # implies another field: movieId: UUID!
  user: User!
  role: String!
}

Применение при мутациях

В приведенном ниже примере реализации мутация UpdateMovieTitle включает поле query для получения данных из MoviePermission , а также следующие директивы для обеспечения безопасности и надежности операции:

• Директива @transaction , гарантирующая атомарное завершение или сбой всех запросов и проверок авторизации.
• Директива @redact исключает результаты запроса из ответа, что означает, что проверка авторизации выполняется на сервере Data Connect но конфиденциальные данные не передаются клиенту.

• Пара директив @check для оценки логики авторизации в результатах запроса, например, для проверки того, имеет ли данный userID соответствующую роль для внесения изменений.

mutation UpdateMovieTitle($movieId: UUID!, $newTitle: String!) @auth(level: USER) @transaction {
  # Step 1: Query and check
  query @redact {
    moviePermission( # Look up a join table called MoviePermission with a compound key.
      key: {movieId: $movieId, userId_expr: "auth.uid"}
    # Step 1a: Use @check to test if the user has any role associated with the movie
    # Here the `this` binding refers the lookup result, i.e. a MoviePermission object or null
    # The `this != null` expression could be omitted since rejecting on null is default behavior
    ) @check(expr: "this != null", message: "You do not have access to this movie") {
      # Step 1b: Check if the user has the editor role for the movie
      # Next we execute another @check; now `this` refers to the contents of the `role` field
      role @check(expr: "this == 'editor'", message: "You must be an editor of this movie to update title")
    }
  }
  # Step 2: Act
  movie_update(id: $movieId, data: {
    title: $newTitle
  })
}

Используйте в запросах

Поиск данных авторизации также полезен для ограничения запросов на основе ролей или других ограничений.

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

query GetMovieEditors($movieId: UUID!) @auth(level: PUBLIC) {
  moviePermission(key: { movieId: $movieId, userId_expr: "auth.uid" }) @redact {
    role @check(expr: "this == 'admin'", message: "You must be an admin to view all editors of a movie.")
  }
  moviePermissions(where: { movieId: { eq: $movieId }, role: { eq: "editor" } }) {
    user {
      id
      username
    }
  }
}

Антишаблоны, которых следует избегать при авторизации.

В предыдущем разделе были рассмотрены шаблоны, которым следует следовать при использовании директивы @auth .

Также следует помнить о важных антипаттернах, которых следует избегать.

Избегайте передачи идентификаторов атрибутов пользователя и параметров токена аутентификации в аргументах запросов и мутаций.

Firebase Authentication — это мощный инструмент для представления потоков аутентификации и безопасного сбора данных аутентификации, таких как зарегистрированные идентификаторы пользователей и многочисленные поля, хранящиеся в токенах аутентификации.

Не рекомендуется передавать идентификаторы пользователей и данные токенов аутентификации в аргументах запросов и мутаций.

# Antipattern!
# This incorrectly allows any user to view any other user's posts
query AllMyPosts($userId: String!) @auth(level: USER) {
  posts(where: {authorUid: {eq: $userId}}) {
    id, text, createdAt
  }
}

Избегайте использования уровня доступа USER без каких-либо фильтров.

Как уже неоднократно обсуждалось в руководстве, основные уровни доступа, такие как USER , USER_ANON , USER_EMAIL_VERIFIED являются базовыми и отправными точками для проверок авторизации, которые можно расширить с помощью фильтров и выражений. Использование этих уровней без соответствующего фильтра или выражения, проверяющего, какой пользователь выполняет запрос, по сути, эквивалентно использованию уровня PUBLIC .

# Antipattern!
# This incorrectly allows any user to view all documents
query ListDocuments @auth(level: USER) {
  documents {
    id
    title
    text
  }
}

Избегайте использования уровней доступа PUBLIC или USER при прототипировании.

Для ускорения разработки может возникнуть соблазн установить для всех операций уровень доступа PUBLIC или USER без дополнительных улучшений, которые бы авторизовали все операции и позволили быстро протестировать код.

После проведения первоначального прототипирования таким способом начните переходить от NO_ACCESS к готовой к использованию в производственной среде авторизации с уровнями PUBLIC и USER . Однако не развертывайте их как PUBLIC или USER без добавления дополнительной логики, как показано в этом руководстве.

# Antipattern!
# This incorrectly allows anyone to delete any post
mutation DeletePost($id: UUID!) @auth(level: PUBLIC) {
  post: post_delete(
    id: $id,
  )
}

Избегайте авторизации на основе непроверенных адресов электронной почты.

Предоставление доступа пользователям в рамках определенного домена — отличный способ ограничить доступ. Однако любой может заявить о владении электронной почтой при входе в систему. Убедитесь, что вы предоставляете доступ только тем адресам электронной почты, которые были подтверждены с помощью аутентификации Firebase.

# Antipattern!
# Anyone can claim an email address during sign-in
mutation CreatePost($text: String!, $visibility: String) @auth(expr: "auth.token.email.endsWith('@example.com')") {
  post_insert(data: {
    # set the author's uid to the current user uid
    authorUid_expr: "auth.uid"
    text: $text
    visibility: $visibility
  })
}

Также проверьте auth.token.email_verified

mutation CreatePost($text: String!, $visibility: String) @auth(expr: "auth.token.email_verified && auth.token.email.endsWith('@example.com')") {
  post_insert(data: {
    # set the author's uid to the current user uid
    authorUid_expr: "auth.uid"
    text: $text
    visibility: $visibility
  })
}

Проверка авторизации с помощью Firebase CLI

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

Data Connect помогает вам провести аудит вашей стратегии авторизации, анализируя код коннектора при развертывании на сервере с помощью firebase deploy из Firebase CLI. Вы можете использовать этот аудит для проверки вашего кода.

При развертывании коннекторов интерфейс командной строки выведет результаты оценки существующего, измененного и нового кода операций в вашем коннекторе.

При изменении и создании новых операций интерфейс командной строки выдает предупреждения и запрашивает подтверждение при использовании определенных уровней доступа в новых операциях или при изменении существующих операций для использования этих уровней доступа.

Предупреждения и подсказки всегда появляются в следующих случаях:

• PUBLIC

Кроме того, предупреждения и запросы появляются на следующих уровнях доступа, если вы не дополняете их фильтрами с использованием auth.uid :

• USER
• USER_ANON
• USER_EMAIL_VERIFIED

Подавлять предупреждения о небезопасных операциях с помощью аргумента @auth(insecureReason:)

Во многих случаях вы придете к выводу, что использование уровней доступа PUBLIC и USER* вполне уместно.

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

Вы можете подавить предупреждения для таких операций с помощью @auth(insecureReason:) . Например:

query listItem @auth(level: PUBLIC, insecureReason: "This operation is safe to expose to the public.")
  {
    items {
      id name
    }
  }

Используйте Firebase App Check для аттестации приложений.

Аутентификация и авторизация являются важнейшими компонентами безопасности Data Connect . Сочетание аутентификации и авторизации с подтверждением подлинности приложения обеспечивает очень надежное решение для обеспечения безопасности.

Благодаря аттестации через Firebase App Check , устройства, на которых работает ваше приложение, будут использовать поставщика аттестации приложений или устройств, который подтверждает, что операции Data Connect инициированы вашим подлинным приложением, а запросы исходят от подлинного, не подвергавшегося изменениям устройства. Эта аттестация прикрепляется к каждому запросу, который ваше приложение отправляет в Data Connect .

Чтобы узнать, как включить App Check для Data Connect и интегрировать клиентский SDK в ваше приложение, ознакомьтесь с обзором App Check .

Уровни аутентификации для директивы @auth(level)

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

Справочник CEL для @auth(expr)

Как показано в примерах в других разделах этого руководства, вы можете и должны использовать выражения, определенные в Common Expression Language (CEL), для управления авторизацией в Data Connect с помощью директив @auth(expr:) и @check .

В этом разделе рассматривается синтаксис CEL, необходимый для создания выражений для этих директив.

Полная справочная информация по CEL представлена ​​в спецификации CEL .

Тестовые переменные передаются в запросах и мутациях.

Синтаксис @auth(expr) позволяет получать доступ к переменным из запросов и мутаций и проверять их.

Например, вы можете включить переменную операции, такую ​​как $status , используя vars.status .

mutation Update($id: UUID!, $status: Any) @auth(expr: "has(vars.status)")

Данные, доступные для выражений: request, response, this

Вы используете данные для:

• Оценка с использованием выражений CEL в директивах @auth(expr:) и @check(expr:)
• Присваивание с использованием серверных выражений, <field>_expr .

Как выражения CEL ` @auth(expr:) , так и @check(expr:) могут оценивать следующее:

• request.operationName
• vars (псевдоним для request.variables )
• auth (псевдоним для request.auth )

При изменении типа данных вы можете получить доступ к содержимому следующих элементов и присвоить его:

• response (для проверки частичных результатов в многошаговой логике)

Кроме того, выражения @check(expr:) могут оцениваться следующим образом:

• this (значение текущего поля)
• response (для проверки частичных результатов в многошаговой логике)

Привязка request.operationName

В привязке request.operarationName хранится тип операции: запрос или изменение.

Привязка vars (request.vars)

Функция привязки vars позволяет вашим выражениям получать доступ ко всем переменным, переданным в вашем запросе или мутации.

Вы можете использовать vars.<variablename> в выражении в качестве псевдонима для полного request.variables.<variablename> `.

# The following are equivalent
mutation StringType($v: String!) @auth(expr: "vars.v == 'hello'")
mutation StringType($v: String!) @auth(expr: "request.variables.v == 'hello'")

Привязка auth (request.auth)

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

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

В привязке аутентификации содержится следующая информация:

• uid : Уникальный идентификатор пользователя, присваиваемый пользователю, отправившему запрос.
• token : Карта значений, собранных в процессе Authentication .

Для получения более подробной информации о содержимом файла auth.token см. раздел «Данные в токенах аутентификации».

response связывания

В привязке response содержатся данные, которые сервер собирает в ответ на запрос или изменение , по мере того, как эти данные собираются .

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

Структура привязки response определяется формой связанной с ним операции, включая (множественные) вложенные поля и (при необходимости) встроенные запросы.

Обратите внимание, что при доступе к данным ответа на встроенный запрос поля могут содержать любые типы данных в зависимости от данных, запрошенных во встроенном запросе; при доступе к данным, возвращаемым полями мутаций, такими как _insert и _delete , они могут содержать ключи UUID, количество удалений, значения NULL (см. справочник по мутациям ).

Например:

• В мутации, содержащей встроенный запрос, привязка response содержит данные для поиска по адресу response.query.<fieldName>.<fieldName>.... , в данном случае, response.query.todoList и response.query.todoList.priority .

mutation CheckTodoPriority(
  $uniqueListName: String!
) {
  # This query is identified as `response.query`
  query @check(expr: "response.query.todoList.priority == 'high'", message: "This list is not for high priority items!") {
    # This field is identified as `response.query.todoList`
    todoList(where: { name: $uniqueListName }) {
      # This field is identified as `response.query.todoList.priority`
      priority
    }
  }
}

• В многошаговой мутации, например, с несколькими полями _insert , привязка response содержит частичные данные по response.<fieldName>.<fieldName>.... , в данном случае, response.todoList_insert.id .

mutation CreateTodoListWithFirstItem(
  $listName: String!,
  $itemContent: String!
) @transaction {
  # Step 1
  todoList_insert(data: {
    id_expr: "uuidV4()",
    name: $listName,
  })
  # Step 2:
  todo_insert(data: {
    listId_expr: "response.todoList_insert.id" # <-- Grab the newly generated ID from the partial response so far.
    content: $itemContent,
  })
}

this переплет

Привязка this выполняет директива @check связана с полем, к которому она прикреплена. В простом случае вы можете оценивать результаты запроса, содержащие одно значение.

mutation UpdateMovieTitle (
  $movieId: UUID!,
  $newTitle: String!)
  @auth(level: USER)
  @transaction {
  # Step 1: Query and check
  query @redact {
    moviePermission( # Look up a join table called MoviePermission with a compound key.
      key: {movieId: $movieId, userId_expr: "auth.uid"}
    ) {
      # Check if the user has the editor role for the movie. `this` is the string value of `role`.
      # If the parent moviePermission is null, the @check will also fail automatically.
      role @check(expr: "this == 'editor'", message: "You must be an editor of this movie to update title")
    }
  }
  # Step 2: Act
  movie_update(id: $movieId, data: {
    title: $newTitle
  })
}

Если возвращаемое поле встречается несколько раз, поскольку какой-либо предок является списком, каждое вхождение проверяется с помощью this к соответствующему значению.

Для любого заданного пути, если предок равен null или [] , то поле не будет достигнуто, и вычисление CEL для этого пути будет пропущено. Другими словами, вычисление происходит только тогда, когда this значение null или не равно null , но никогда не undefined .

Если само поле представляет собой список или объект, this имеет ту же структуру (включая всех потомков, выбранных в случае объектов), как показано в следующем примере.

mutation UpdateMovieTitle2($movieId: UUID!, $newTitle: String!) @auth(level: USER) @transaction {
  # Step 1: Query and check
  query {
    moviePermissions( # Now we query for a list of all matching MoviePermissions.
      where: {movieId: {eq: $movieId}, userId: {eq_expr: "auth.uid"}}
    # This time we execute the @check on the list, so `this` is the list of objects.
    # We can use the `.exists` macro to check if there is at least one matching entry.
    ) @check(expr: "this.exists(p, p.role == 'editor')", message: "You must be an editor of this movie to update title") {
      role
    }
  }
  # Step 2: Act
  movie_update(id: $movieId, data: {
    title: $newTitle
  })
}

Сложный синтаксис выражений

Более сложные выражения можно создавать, комбинируя операторы && и || .

mutation UpsertUser($username: String!) @auth(expr: "(auth != null) && (vars.username == 'joe')")

В следующем разделе описаны все доступные операторы.

Операторы и приоритет операторов

Используйте следующую таблицу в качестве справочника по операторам и их соответствующему приоритету.

Пусть заданы произвольные выражения a и b , поле f и индекс i .

Данные в токенах аутентификации

Объект auth.token может содержать следующие значения:

Дополнительные поля в токенах JWT ID

Вы также можете получить доступ к следующим полям auth.token :

Что дальше?

• Firebase Data Connect предоставляет Admin SDK, позволяющий выполнять запросы и изменения данных из привилегированных сред .
• Подробнее о безопасности IAM можно узнать в руководстве по управлению службами и базами данных .