Функции, связанные с базами данных, для построителя API данных

Статья
04/13/2024

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

Поддержка версий базы данных

Для многих традиционных баз данных требуется минимальная версия для совместимости с конструктором API данных (DAB).

	Минимальная поддерживаемая версия
SQL Server	2016
MySQL	8
PostgreSQL	11

И наоборот, службы облачных баз данных Azure работают с DAB без необходимости в определенной версии.

	Минимальная поддерживаемая версия
Azure SQL;	Недоступно
Azure Cosmos DB for NoSQL	Недоступно
Azure Cosmos DB for PostgreSQL	Недоступно

Azure SQL и SQL Server

Существует несколько уникальных свойств SQL, включая Azure SQL и SQL Server.

SESSION_CONTEXT

Azure SQL и SQL Server поддерживают использование SESSION_CONTEXT функции для доступа к удостоверению текущего пользователя. Эта функция полезна, если вы хотите применить встроенную поддержку безопасности на уровне строк (RLS), доступную в Azure SQL и SQL Server.

Для Azure SQL и SQL Server построитель API данных может воспользоваться преимуществами SESSION_CONTEXT для отправки указанных пользователем метаданных в базовую базу данных. Такие метаданные доступны конструктору API данных благодаря утверждениям, присутствующим в маркере доступа. Затем данные, отправляемые в базу данных, можно использовать для настройки дополнительного уровня безопасности (например, путем настройки политик безопасности), чтобы дополнительно предотвратить доступ к данным в таких операциях, как SELECT, UPDATE, DELETE. Данные SESSION_CONTEXT будут доступны для базы данных во время подключения к базе данных, пока это подключение не будет закрыто. Одни и те же данные можно использовать и в хранимой процедуре.

Дополнительные сведения о настройке SESSION_CONTEXT данных см. в разделе sp_set_session_context (Transact-SQL).

Настройте SESSION_CONTEXT с options помощью свойства data-source раздела в файле конфигурации. Дополнительные сведения см. в справочникеdata-source по конфигурации.

{
  ...
  "data-source": {
    "database-type": "mssql",
    "options": {
      "set-session-context": true
    },
    "connection-string": "<connection-string>"
  },
  ...
}

Кроме того, используйте --set-session-context аргумент с командой dab init .

dab init --database-type mssql --set-session-context true

Все утверждения, присутствующие в маркере EasyAuth/JWT, отправляются через SESSION_CONTEXT в базовую базу данных. Все утверждения, присутствующие в маркере, претворяются в пары "ключ-значение", передаваемые с помощью SESSION_CONTEXT запроса. К этим утверждениям относятся, помимо прочего, следующие:

	Описание
`aud`	Аудитория
`iss`	Издатель
`iat`	Время выдачи
`exp`	Время окончания срока действия
`azp`	Идентификатор приложения
`azpacr`	Метод проверки подлинности клиента
`name`	Тема
`uti`	Уникальный идентификатор маркера

Дополнительные сведения о утверждениях см. в Microsoft Entra ID справочнике по утверждениям маркеров доступа.

Эти утверждения претворяются в SQL-запрос. В этом усеченном примере показано, как sp_set_session_context используется в этом контексте:

EXEC sp_set_session_context 'aud', '<AudienceID>', @read_only = 1;
EXEC sp_set_session_context 'iss', 'https://login.microsoftonline.com/<TenantID>/v2.0', @read_only = 1;
EXEC sp_set_session_context 'iat', '1637043209', @read_only = 1;
...
EXEC sp_set_session_context 'azp', 'a903e2e6-fd13-4502-8cae-9e09f86b7a6c', @read_only = 1;
EXEC sp_set_session_context 'azpacr', 1, @read_only = 1;
..
EXEC sp_set_session_context 'uti', '_sSP3AwBY0SucuqqJyjEAA', @read_only = 1;
EXEC sp_set_session_context 'ver', '2.0', @read_only = 1;

Затем можно реализовать безопасность на уровне строк (RLS), используя данные сеанса. Дополнительные сведения см. в статье Реализация безопасности на уровне строк с контекстом сеанса.

Azure Cosmos DB

Существует несколько конкретных свойств, которые являются уникальными для различных API в Azure Cosmos DB.

Схема в API для NoSQL

Azure Cosmos DB для NoSQL не зависит от схемы. Чтобы использовать построитель API данных с API для NoSQL, необходимо создать файл схемы GraphQL, включающий определения типов объектов, представляющих модель данных контейнера. Построитель API данных также ожидает, что определения и поля типов объектов GraphQL будут включать директиву authorize схемы GraphQL, если требуется применить более строгий доступ на чтение, чем anonymous.

Например, этот файл схемы представляет Book элемент в контейнере. Этот элемент содержит как минимум title свойства и Authors .

type Book @model(name:"Book"){
  id: ID
  title: String @authorize(roles:["metadataviewer","authenticated"])
  Authors: [Author]
}

Этот пример схемы соответствует следующей конфигурации сущности в файле конфигурации DAB. Дополнительные сведения см. в справочникеentities по конфигурации.

{
  ...
  "Book": {
    "source": "Book",
    "permissions": [
      {
        "role": "anonymous",
        "actions": [ "read" ]
      },
      {
        "role": "metadataviewer",
        "actions": [ "read" ]
      }
    ]
  }
  ...
}

Директива @authorize с roles:["metadataviewer","authenticated"] ограничивает доступ к полю title только пользователям с ролями metadataviewer и authenticated. Для аутентифицированных запрашивающих пользователей системная роль authenticated назначается автоматически, устраняя необходимость в заголовке X-MS-API-ROLE .

Если запрос, прошедший проверку подлинности, должен выполняться в контексте metadataviewer, он должен сопровождаться заголовком запроса типа X-MS-API-ROLE , для которых задано значение metadataviewer. Однако если требуется анонимный доступ, необходимо опустить разрешенную директиву.

Директива @model используется для установления корреляции между этим GraphQL типом объекта и соответствующим именем сущности в конфигурации среды выполнения. Директива имеет следующий формат:@model(name:"<Entity_Name>")

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

type Series @model(name:"Series") @authorize(roles:["editor","authenticated"]) {
  id: ID
  title: String
  Books: [Book]
}

{
  "Book": {
    "source": "Series",
    "permissions": [
      {
        "role": "authenticated",
        "actions": [ "read" ]
      },
      {
        "role": "editor",
        "actions": [ "*" ]
      }
    ]
  }
}

Межконтейнерные запросы в API для NoSQL

GraphQL операции в контейнерах не поддерживаются. Подсистема отвечает сообщением об ошибке: Adding/updating Relationships is currently not supported in Azure Cosmos DB for NoSQL.

Это ограничение можно обойти, обновив модель данных для хранения сущностей в одном контейнере во внедренном формате. Дополнительные сведения см. в статье Моделирование данных в Azure Cosmos DB для NoSQL.

Поделиться через