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

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

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

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

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

Azure SQL и SQL Server

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

SESSION_CONTEXT

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

Для SQL Azure и 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 запрос. Эти утверждения включают в себя, но не ограничиваются следующими:

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

Эти утверждения превратятся в 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 (облачная база данных)

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

Схема в API для NoSQL

Azure Cosmos DB для NoSQL — это не зависящая от схемы. Чтобы использовать построитель данных с API noSQL, необходимо создать файл схемы GraphQL, включающий определения типов объектов, представляющие модель данных контейнера. Построитель данных также ожидает определения типов объектов 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.