Fonctionnalités spécifiques à la base de données pour le générateur d’API de données

Article
04/13/2024

Le générateur d’API de données permet à chaque base de données d’avoir ses propres fonctionnalités spécifiques. Cet article détaille les fonctionnalités prises en charge pour chaque base de données.

Prise en charge des versions de base de données

De nombreuses bases de données traditionnelles nécessitent une version minimale pour être compatible avec le Générateur d’API de données (DAB).

	Version minimale prise en charge
SQL Server	2016
MySQL	8
PostgreSQL	11

À l’inverse, les services de base de données cloud Azure fonctionnent avec DAB prêtes à l’emploi sans nécessiter une version spécifique.

	Version minimale prise en charge
Azure SQL	n/a
Azure Cosmos DB pour NoSQL	n/a
Azure Cosmos DB pour PostgreSQL	n/a

Azure SQL et SQL Server

Il existe quelques propriétés spécifiques propres à SQL, notamment Azure SQL et SQL Server.

SESSION_CONTEXT

Azure SQL et SQL Server prennent en charge l’utilisation de la SESSION_CONTEXT fonction pour accéder à l’identité de l’utilisateur actuel. Cette fonctionnalité est utile lorsque vous souhaitez appliquer la prise en charge native de la sécurité au niveau des lignes (RLS) disponible dans Azure SQL et SQL Server.

Par Azure SQL et SQL Server, le Générateur d’API de données peut en tirer parti pour envoyer des SESSION_CONTEXT métadonnées spécifiées par l’utilisateur à la base de données sous-jacente. Ces métadonnées sont disponibles pour le générateur d’API de données en vertu des revendications présentes dans le jeton d’accès. Les données envoyées à la base de données peuvent ensuite être utilisées pour configurer un niveau de sécurité supplémentaire (par exemple, en configurant des stratégies de sécurité) afin d’empêcher davantage l’accès aux données dans des opérations telles que SELECT, UPDATE, DELETE. Les SESSION_CONTEXT données sont disponibles pour la base de données pendant la connexion à la base de données jusqu’à ce que cette connexion soit fermée. Les mêmes données peuvent également être utilisées à l’intérieur d’une procédure stockée.

Pour plus d’informations sur la définition des SESSION_CONTEXT données, consultez sp_set_session_context (Transact-SQL).

Configurez SESSION_CONTEXT à l’aide de la options propriété de la data-source section dans le fichier de configuration. Pour plus d’informations, consultez data-source informations de référence sur la configuration.

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

Vous pouvez également utiliser l’argument --set-session-context avec la dab init commande .

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

Toutes les revendications présentes dans le jeton EasyAuth/JWT sont envoyées via la SESSION_CONTEXT base de données sous-jacente. Toutes les revendications présentes dans le jeton sont traduites en paires clé-valeur transmises via SESSION_CONTEXT une requête. Ces revendications incluent, mais ne sont pas limitées à :

	Description
`aud`	Public visé
`iss`	Émetteur
`iat`	Émis à
`exp`	Heure d’expiration
`azp`	Identificateur d’application
`azpacr`	Méthode d’authentification du client
`name`	Objet
`uti`	Identificateur de jeton unique

Pour plus d’informations sur les revendications, consultez Microsoft Entra ID référence sur les revendications de jeton d’accès.

Ces revendications sont traduites en requête SQL. Cet exemple tronqué illustre comment sp_set_session_context est utilisé dans ce contexte :

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;

Vous pouvez ensuite implémenter la sécurité au niveau des lignes (RLS) à l’aide des données de session. Pour plus d’informations, consultez Implémenter la sécurité au niveau des lignes avec le contexte de session.

Azure Cosmos DB

Il existe quelques propriétés spécifiques qui sont propres à différentes API dans Azure Cosmos DB.

Schéma dans l’API pour NoSQL

La solution Azure Cosmos DB for NoSQL est indépendante du schéma. Pour utiliser le générateur d’API de données avec l’API pour NoSQL, vous devez créer un fichier de schéma GraphQL qui inclut les définitions de type d’objet représentant le modèle de données de votre conteneur. Le générateur d’API de données s’attend également à ce que vos GraphQL définitions et champs de type d’objet incluent la directive authorize de schéma GraphQL lorsque vous souhaitez appliquer un accès en lecture plus restrictif que anonymous.

Par exemple, ce fichier de schéma représente un Book élément dans un conteneur. Cet élément contient, au minimum, title et Authors des propriétés.

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

Cet exemple de schéma correspond à la configuration d’entité suivante dans le fichier de configuration DAB. Pour plus d’informations, consultez entities informations de référence sur la configuration.

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

La @authorize directive avec roles:["metadataviewer","authenticated"] limite l’accès au title champ aux utilisateurs disposant des rôles metadataviewer et authenticated. Pour les demandeurs authentifiés, le rôle authenticated système est automatiquement attribué, ce qui élimine le besoin d’un X-MS-API-ROLE en-tête.

Si la demande authentifiée doit être exécutée dans le contexte de metadataviewer, elle doit être accompagnée d’un en-tête de requête de type X-MS-API-ROLE défini sur metadataviewer. Toutefois, si l’accès anonyme est souhaité, vous devez omettre la directive autorisée.

La @model directive est utilisée pour établir une corrélation entre ce type d’objet GraphQL et le nom d’entité correspondant dans la configuration du runtime. La directive est mise en forme comme suit :@model(name:"<Entity_Name>")

Par exemple, la @authorize directive peut être appliquée à la définition de type de niveau supérieur. Cette application limite l’accès au type et à ses champs exclusivement aux rôles spécifiés dans la directive.

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": [ "*" ]
      }
    ]
  }
}

Requêtes inter-conteneurs dans l’API pour NoSQL

GraphQL opérations entre les conteneurs ne sont pas prises en charge. Le moteur répond avec un message d’erreur indiquant : Adding/updating Relationships is currently not supported in Azure Cosmos DB for NoSQL.

Vous pouvez contourner cette limitation en mettant à jour votre modèle de données pour stocker des entités dans le même conteneur dans un format incorporé. Pour plus d’informations, consultez Modélisation des données dans Azure Cosmos DB for NoSQL.

Partager via