Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
O construtor de API de dados permite que cada banco de dados tenha seus próprios recursos específicos. Este artigo detalha os recursos suportados para cada banco de dados.
Suporte à versão do banco de dados
Muitos bancos de dados tradicionais exigem uma versão mínima para serem compatíveis com o Data API Builder (DAB).
| Versão mínima suportada | |
|---|---|
| SQL Server | 2016 |
| MySQL | 8 |
| PostgreSQL | 11 |
Por outro lado, os serviços de banco de dados em nuvem do Azure funcionam com DAB pronto para uso sem exigir uma versão específica.
| Versão mínima suportada | |
|---|---|
| Azure SQL | n/a |
| Azure Cosmos DB para NoSQL | n/a |
| Azure Cosmos DB para PostgreSQL | n/a |
SQL Azure e Servidores SQL
Há algumas propriedades específicas que são exclusivas do SQL, incluindo o SQL do Azure e o SQL Server.
SESSION_CONTEXT
O SQL do Azure e o SESSION_CONTEXT SQL Server dão suporte ao uso da função para acessar a identidade do usuário atual. Esse recurso é útil quando você deseja aplicar o suporte nativo para segurança em nível de linha (RLS) disponível no SQL do Azure e no SQL Server.
Para o SQL do Azure e o SQL Server, o construtor de API de Dados pode aproveitar SESSION_CONTEXT para enviar metadados especificados pelo usuário para o banco de dados subjacente. Esses metadados estão disponíveis para o construtor de API de dados em virtude das declarações presentes no token de acesso. Os dados enviados para o banco de dados podem ser usados para configurar um nível extra de segurança (por exemplo, configurando políticas de segurança) para impedir ainda mais o acesso aos dados em operações como SELECT, UPDATE, DELETE. Os dados SESSION_CONTEXT ficam disponíveis para o banco de dados durante a conexão do banco de dados até que essa conexão seja fechada. Os mesmos dados também podem ser usados dentro de um procedimento armazenado.
Para obter mais informações sobre como definir SESSION_CONTEXT dados, consulte sp_set_session_context (Transact-SQL).
Configure SESSION_CONTEXT usando a optionsdata-source propriedade da seção no arquivo de configuração. Para obter mais informações, consulte data-source Referência de configuração.
{
...
"data-source": {
"database-type": "mssql",
"options": {
"set-session-context": true
},
"connection-string": "<connection-string>"
},
...
}
Como alternativa, use o --set-session-context argumento com o dab init comando.
dab init --database-type mssql --set-session-context true
Todas as declarações presentes no token EasyAuth/JWT são enviadas através do SESSION_CONTEXT para o banco de dados subjacente. Todas as declarações presentes no token são traduzidas em pares chave-valor passados via SESSION_CONTEXT consulta. Essas reivindicações incluem, mas não estão limitadas a:
| Description | |
|---|---|
aud |
Audience |
iss |
Issuer |
iat |
Issued at |
exp |
Expiration time |
azp |
Application identifier |
azpacr |
Método de autenticação do cliente |
name |
Subject |
uti |
Identificador de token exclusivo |
Para obter mais informações sobre declarações, consulte Referência de declarações de token de acesso do Microsoft Entra ID.
Essas declarações são traduzidas em uma consulta SQL. Este exemplo truncado ilustra como sp_set_session_context é usado neste contexto:
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;
Em seguida, você pode implementar a segurança em nível de linha (RLS) usando os dados da sessão. Para obter mais informações, consulte implementar segurança em nível de linha com contexto de sessão.
Azure Cosmos DB
Há algumas propriedades específicas que são exclusivas para várias APIs no Azure Cosmos DB.
Esquema na API para NoSQL
O Azure Cosmos DB para NoSQL é independente do esquema. Para usar o construtor de API de dados com a API para NoSQL, você deve criar um arquivo de esquema GraphQL que inclua as definições de tipo de objeto que representam o modelo de dados do contêiner. O construtor de API de dados também espera que suas definições e campos de tipo de objeto GraphQL incluam a diretiva authorize de esquema GraphQL quando você quiser impor acesso de leitura mais restritivo do que anonymous.
Por exemplo, esse arquivo de esquema representa um Book item dentro de um contêiner. Este item contém, no mínimo, title e Authors propriedades.
type Book @model(name:"Book"){
id: ID
title: String @authorize(roles:["metadataviewer","authenticated"])
Authors: [Author]
}
Este esquema de exemplo corresponde à seguinte configuração de entidade no arquivo de configuração DAB. Para obter mais informações, consulte entities Referência de configuração.
{
...
"Book": {
"source": "Book",
"permissions": [
{
"role": "anonymous",
"actions": [ "read" ]
},
{
"role": "metadataviewer",
"actions": [ "read" ]
}
]
}
...
}
A @authorize diretiva restringe roles:["metadataviewer","authenticated"] o title acesso ao campo apenas aos utilizadores com as funções metadataviewer e authenticated. Para solicitantes autenticados, a função authenticated do sistema é atribuída automaticamente, eliminando a necessidade de um X-MS-API-ROLE cabeçalho.
Se a solicitação autenticada precisar ser executada no contexto de metadataviewer, ela deverá ser acompanhada de um cabeçalho de solicitação do tipo X-MS-API-ROLE definido como metadataviewer. No entanto, se o acesso anônimo for desejado, você deve omitir a diretiva autorizada.
A @model diretiva é utilizada para estabelecer uma correlação entre esse tipo de objeto GraphQL e o nome da entidade correspondente na configuração de tempo de execução. A diretiva está formatada como: @model(name:"<Entity_Name>")
Como exemplo mais profundo, a @authorize diretiva pode ser aplicada na definição de tipo de nível superior. Esta aplicação restringe o acesso ao tipo e seus campos exclusivamente às funções especificadas na diretiva.
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": [ "*" ]
}
]
}
}
Consultas entre contêineres na API para NoSQL
Não há suporte para operações GraphQL em contêineres. O mecanismo responde com uma mensagem de erro informando, Adding/updating Relationships is currently not supported in Azure Cosmos DB for NoSQL.
Você pode contornar essa limitação atualizando seu modelo de dados para armazenar entidades dentro do mesmo contêiner em um formato incorporado. Para obter mais informações, consulte Modelagem de dados no Azure Cosmos DB para NoSQL.