Tutorial: Alojar uma API RESTful com CORS no Serviço de Aplicações do Azure

  • Artigo

O Serviço de Aplicações do Azure oferece um serviço de alojamento na Web altamente dimensionável e com correção automática. Além disso, o Serviço de Aplicações tem suporte incorporado para Partilha de Recursos de Várias Origens (CORS) para APIs RESTful. Este tutorial mostra como implementar uma aplicação API ASP.NET Core no Serviço de Aplicações com suporte para CORS. A aplicação é configurada com ferramentas de linha de comandos e implementada na aplicação através do Git.

Neste tutorial, irá aprender a:

  • Criar recursos do Serviço de Aplicações com a CLI do Azure
  • Implementar uma API RESTful no Azure com o Git
  • Ativar o suporte para CORS no Serviço de Aplicações

Pode seguir os passos neste tutorial em macOS, Linux e Windows.

Se não tiver uma subscrição do Azure, crie uma conta gratuita do Azure antes de começar.

Pré-requisitos

Para concluir este tutorial:

Criar uma aplicação .NET Core local

Neste passo, vai configurar o projeto ASP.NET Core local. O Serviço de Aplicações suporta o mesmo fluxo de trabalho para APIs escritas noutras linguagens.

Clonar a aplicação de exemplo

  1. Na janela de terminal, cd num diretório de trabalho.

  2. Clone o repositório de exemplo e mude para a raiz do repositório.

    git clone https://github.com/Azure-Samples/dotnet-core-api
cd dotnet-core-api

    Este repositório contém uma aplicação que é criada com base no tutorial ASP.NET Core Web API help pages using Swagger (Páginas de ajuda da API Web ASP.NET Core mediante a utilização do Swagger). Utiliza um gerador do Swagger para servir a IU do Swagger e o ponto final JSON do Swagger.

  3. Verifique se a ramificação padrão é main.

    git branch -m main

    Gorjeta

    A alteração do nome da filial não é exigida pelo Serviço de Aplicativo. No entanto, como muitos repositórios estão alterando sua ramificação padrão para main (consulte Alterar ramificação de implantação), este tutorial também mostra como implantar um repositório a partir do main.

Executar a aplicação

  1. Execute os seguintes comandos para instalar os pacotes necessários, executar migrações de base de dados e iniciar a aplicação.

    dotnet restore
dotnet run

  2. Navegue para http://localhost:5000/swagger num browser para reproduzir com a IU do Swagger.

    ASP.NET Core API running locally

  3. Navegue para http://localhost:5000/api/todo e veja uma lista de itens JSON ToDo

  4. Navegue para http://localhost:5000 e experimente a aplicação de browser. Mais tarde, vai apontar a aplicação de browser para uma API remota no Serviço de Aplicações para testar a funcionalidade CORS. O código para a aplicação de browser está no diretório wwwroot do repositório.

  5. Para parar o ASP.NET Core em qualquer altura, prima Ctrl+C no terminal.

Azure Cloud Shell

O Azure aloja o Azure Cloud Shell, um ambiente de shell interativo que pode utilizar através do seu browser. Pode utilizar o Bash ou o PowerShell com o Cloud Shell para trabalhar com os serviços do Azure. Você pode usar os comandos pré-instalados do Cloud Shell para executar o código neste artigo, sem precisar instalar nada em seu ambiente local.

Para iniciar o Azure Cloud Shell:

Opção Exemplo/Ligação
Selecione Experimentar no canto superior direito de um código ou bloco de comandos. Selecionar Experimentar não copia automaticamente o código ou comando para o Cloud Shell. Screenshot that shows an example of Try It for Azure Cloud Shell.
Aceda a https://shell.azure.com ou selecione o botão Iniciar Cloud Shell para abrir o Cloud Shell no browser. Button to launch Azure Cloud Shell.
Selecione o botão Cloud Shell na barra de menus, na parte direita do portal do Azure. Screenshot that shows the Cloud Shell button in the Azure portal

Para usar o Azure Cloud Shell:

  1. Inicie o Cloud Shell.

  2. Selecione o botão Copiar em um bloco de código (ou bloco de comando) para copiar o código ou comando.

  3. Cole o código ou comando na sessão do Cloud Shell selecionando Ctrl+Shift+V no Windows e Linux ou selecionando Cmd+Shift+V no macOS.

  4. Selecione Enter para executar o código ou comando.

Implementar a aplicação no Azure

Nesta etapa, você implanta seu aplicativo .NET Core no Serviço de Aplicativo.

Configurar a implementação do git local

O FTP e o Git local podem ser implantados em um aplicativo Web do Azure usando um usuário de implantação. Depois de configurar seu usuário de implantação, você pode usá-lo para todas as suas implantações do Azure. Seu nome de usuário e senha de implantação no nível de conta são diferentes de suas credenciais de assinatura do Azure.

Para configurar o usuário de implantação, execute o comando az webapp deployment user set no Azure Cloud Shell. Substitua <o nome> de usuário e <a senha> por um nome de usuário e senha de usuário de implantação.

  • O nome de usuário deve ser exclusivo no Azure e, para pushes locais do Git, não deve conter o símbolo '@'.
  • A senha deve ter pelo menos oito caracteres, com dois dos três elementos a seguir: letras, números e símbolos.
az webapp deployment user set --user-name <username> --password <password>

A saída JSON mostra a senha como null. Se obtiver o erro 'Conflict'. Details: 409, altere o nome de utilizador. Se obtiver o 'Bad Request'. Details: 400 erro, utilize uma palavra-passe mais forte.

Registre seu nome de usuário e senha para usar para implantar seus aplicativos Web.

Criar um grupo de recursos

Um grupo de recursos é um contêiner lógico no qual os recursos do Azure, como aplicativos Web, bancos de dados e contas de armazenamento, são implantados e gerenciados. Por exemplo, pode optar por eliminar todo o grupo de recursos num único passo simples mais tarde.

No Cloud Shell, crie um grupo de recursos com o comando az group create. O exemplo seguinte cria um grupo de recursos com o nome myResourceGroup, na localização Europa Ocidental. Para ver todas as localizações suportadas para o Serviço de Aplicações no escalão Gratuito, execute o comando az appservice list-locations --sku FREE.

az group create --name myResourceGroup --location "West Europe"

Geralmente, o grupo de recursos e os recursos são criados numa região perto de si.

Quando o comando for concluído, uma saída JSON mostra as propriedades do grupo de recursos.

Criar um plano do Serviço de Aplicações

No Cloud Shell, crie um plano do Serviço de Aplicações com o comando az appservice plan create.

O exemplo seguinte cria um plano do Serviço de Aplicações com o nome myAppServicePlan, que utiliza o escalão de preços Gratuito.

az appservice plan create --name myAppServicePlan --resource-group myResourceGroup --sku FREE

Quando o plano do Serviço de Aplicações tiver sido criado, a CLI do Azure mostra informações semelhantes ao seguinte exemplo:

{ 
  "adminSiteName": null,
  "appServicePlanName": "myAppServicePlan",
  "geoRegion": "West Europe",
  "hostingEnvironmentProfile": null,
  "id": "/subscriptions/0000-0000/resourceGroups/myResourceGroup/providers/Microsoft.Web/serverfarms/myAppServicePlan",
  "kind": "app",
  "location": "West Europe",
  "maximumNumberOfWorkers": 1,
  "name": "myAppServicePlan",
  < JSON data removed for brevity. >
  "targetWorkerSizeId": 0,
  "type": "Microsoft.Web/serverfarms",
  "workerTierName": null
}

Criar uma aplicação Web

Crie uma aplicação Web no plano do Serviço de Aplicações myAppServicePlan.

Na Cloud Shell, pode utilizar o comando az webapp create. No exemplo a seguir, substitua <app-name> com um nome de aplicação globalmente exclusivo (os carateres válidos são a-z, 0-9 e -).

az webapp create --resource-group myResourceGroup --plan myAppServicePlan --name <app-name> --deployment-local-git

Quando a aplicação Web tiver sido criada, a CLI do Azure mostra informações semelhantes ao seguinte exemplo:

Local git is configured with url of 'https://<username>@<app-name>.scm.azurewebsites.net/<app-name>.git'
{
  "availabilityState": "Normal",
  "clientAffinityEnabled": true,
  "clientCertEnabled": false,
  "clientCertExclusionPaths": null,
  "cloningInfo": null,
  "containerSize": 0,
  "dailyMemoryTimeQuota": 0,
  "defaultHostName": "<app-name>.azurewebsites.net",
  "deploymentLocalGitUrl": "https://<username>@<app-name>.scm.azurewebsites.net/<app-name>.git",
  "enabled": true,
  < JSON data removed for brevity. >
}

Nota

O URL do Git remoto é apresentado na propriedade deploymentLocalGitUrl, com o formato https://<username>@<app-name>.scm.azurewebsites.net/<app-name>.git. Guarde este URL, uma vez que vai precisar dele mais tarde.

Enviar para o Azure a partir do Git

  1. Como você está implantando a main ramificação, precisa definir a ramificação de implantação padrão para seu aplicativo do Serviço de Aplicativo como main (consulte Alterar ramificação de implantação). No Cloud Shell, defina a configuração do DEPLOYMENT_BRANCH aplicativo com o az webapp config appsettings set comando.

    az webapp config appsettings set --name <app-name> --resource-group myResourceGroup --settings DEPLOYMENT_BRANCH='main'

  2. Regresse à janela de terminal local e adicione um remoto do Azure ao seu repositório Git local. Substitua deploymentLocalGitUrl-from-create-step> pela URL do controle remoto Git que você salvou em Criar um aplicativo Web.<

    git remote add azure <deploymentLocalGitUrl-from-create-step>

  3. Envie para o remoto do Azure para implementar a sua aplicação com o comando seguinte. Quando o Git Credential Manager solicitar credenciais, certifique-se de inserir as credenciais criadas em Configurar um usuário de implantação, não as credenciais usadas para entrar no portal do Azure.

    git push azure main

    Este comando pode demorar alguns minutos a ser executado. Ao executar, apresenta informações semelhantes ao exemplo seguinte:

   Enumerating objects: 83, done.
   Counting objects: 100% (83/83), done.
   Delta compression using up to 8 threads
   Compressing objects: 100% (78/78), done.
   Writing objects: 100% (83/83), 22.15 KiB | 3.69 MiB/s, done.
   Total 83 (delta 26), reused 0 (delta 0)
   remote: Updating branch 'master'.
   remote: Updating submodules.
   remote: Preparing deployment for commit id '509236e13d'.
   remote: Generating deployment script.
   remote: Project file path: .\TodoApi.csproj
   remote: Generating deployment script for ASP.NET MSBuild16 App
   remote: Generated deployment script files
   remote: Running deployment command...
   remote: Handling ASP.NET Core Web Application deployment with MSBuild16.
   remote: .
   remote: .
   remote: .
   remote: Finished successfully.
   remote: Running post deployment command(s)...
   remote: Triggering recycle (preview mode disabled).
   remote: Deployment successful.
   To https://<app_name>.scm.azurewebsites.net/<app_name>.git
   * [new branch]      master -> master

Navegue até o aplicativo do Azure

  1. Navegue para http://<app_name>.azurewebsites.net/swagger num browser experimente a IU do Swagger.

    ASP.NET Core API running in Azure App Service

  2. Navegue para http://<app_name>.azurewebsites.net/swagger/v1/swagger.json para ver o swagger.json da API implementada.

  3. Navegue para http://<app_name>.azurewebsites.net/api/todo para ver a API implementada em funcionamento.

Adicionar a funcionalidade CORS

Em seguida, ative o suporte de CORS no Serviço de Aplicações para a sua API.

Testar CORS na aplicação de exemplo

  1. No seu repositório local, abra wwwroot/index.html.

  2. Na Linha 51, defina a variável apiEndpoint como o URL da API implementada (http://<app_name>.azurewebsites.net). Substitua <appname> pelo nome do aplicativo no Serviço de Aplicativo.

  3. Na janela de terminal local, execute novamente a aplicação de exemplo.

    dotnet run

  4. Navegue para a aplicação de browser em http://localhost:5000. Abra a janela das ferramentas de programador no navegador (Ctrl+Shifti+no Chrome para Windows) e inspecione o separador Consola. Agora você deve ver a mensagem de erro, No 'Access-Control-Allow-Origin' header is present on the requested resource.

    CORS error in browser client

    A incompatibilidade de domínio entre o aplicativo do navegador (http://localhost:5000) e o recurso remoto (http://<app_name>.azurewebsites.net) é reconhecida pelo seu navegador como uma solicitação de recurso entre origens. Além disso, o fato de sua API REST o aplicativo do Serviço de Aplicativo não estar enviando o Access-Control-Allow-Origin cabeçalho, o navegador impediu o carregamento de conteúdo entre domínios.

    Na produção, a aplicação de browser teria um URL público em vez do URL de localhost, mas a forma de ativar o CORS para um URL de localhost é igual à dos URLs públicos.

Ativar o CORS

No Cloud Shell, ative CORS no URL do seu cliente com o comando az webapp cors add. Substitua o espaço reservado para o nome> do <aplicativo.

az webapp cors add --resource-group myResourceGroup --name <app-name> --allowed-origins 'http://localhost:5000'

Você pode adicionar várias origens permitidas executando o comando várias vezes ou adicionando uma lista separada por vírgulas no --allowed-origins. Para permitir todas as origens, use --allowed-origins '*'.

Testar o CORS novamente

Ative a aplicação de browser em http://localhost:5000. A mensagem de erro na janela Consola deixa de estar visível e pode ver os dados da API implementada e interagir com os mesmos. A API remota suporta agora CORS na sua aplicação de browser em execução no local.

CORS success in browser client

Parabéns! Está a executar uma API no Serviço de Aplicações do Azure com suporte para CORS.

Perguntas mais frequentes

CORS do Serviço de Aplicações vs. o seu CORS

Pode utilizar os seus próprios utilitários CORS em vez do CORS do Serviço de Aplicações para uma maior flexibilidade. Por exemplo, poderá querer especificar diferentes origens permitidas para rotas ou métodos diferentes. Uma vez que o CORS do Serviço de Aplicações lhe permite especificar um conjunto de origens aceites para todas as rotas e métodos da API, poderá pretender utilizar o seu próprio código de CORS. Veja como é que o ASP.NET Core o faz em Enabling Cross-Origin Requests (CORS) (Ativar Pedidos de Várias Origens [CORS]).

O recurso CORS interno do Serviço de Aplicativo não tem opções para permitir apenas métodos HTTP ou verbos específicos para cada origem especificada. Ele permitirá automaticamente todos os métodos e cabeçalhos para cada origem definida. Esse comportamento é semelhante a ASP.NET principais políticas CORS quando você usa as opções .AllowAnyHeader() e .AllowAnyMethod() no código.

Nota

Não tente utilizar o CORS do Serviço de Aplicações o seu próprio código CORS em conjunto. Quando utilizados em conjunto, o CORS do Serviço de Aplicações tem precedência e o seu código não tem qualquer efeito.

Como defino origens permitidas para um subdomínio curinga?

Um subdomínio curinga como *.contoso.com é mais restritivo do que a origem *curinga. No entanto, a página de gerenciamento CORS do aplicativo no portal do Azure não permite definir um subdomínio curinga como uma origem permitida. No entanto, você pode fazer isso usando a CLI do Azure, assim:

az webapp cors add --resource-group <group-name> --name <app-name> --allowed-origins 'https://*.contoso.com'

Como faço para ativar o cabeçalho ACCESS-CONTROL-ALLOW-CREDENTIALS na resposta?

Se o seu aplicativo exigir o envio de credenciais, como cookies ou tokens de autenticação, o navegador poderá exigir o ACCESS-CONTROL-ALLOW-CREDENTIALS cabeçalho na resposta. Para habilitar isso no Serviço de Aplicativo, defina properties.cors.supportCredentials como true.

az resource update --name web --resource-group <group-name> \
  --namespace Microsoft.Web --resource-type config \
  --parent sites/<app-name> --set properties.cors.supportCredentials=true

Esta operação não é permitida quando as origens permitidas incluem a origem '*'curinga. Especificar AllowAnyOrigin e AllowCredentials é uma configuração insegura e pode resultar em falsificação de solicitação entre sites. Para permitir credenciais, tente substituir a origem curinga por subdomínios curinga.

Clean up resources (Limpar recursos)

Nos passos anteriores, criou os recursos do Azure num grupo de recursos. Se achar que não vai precisar destes recursos no futuro, execute o seguinte comando no Cloud Shell para eliminar o grupo de recursos:

az group delete --name myResourceGroup

Este comando pode demorar alguns minutos a ser executado.

Próximos passos

O que aprendeu:

  • Criar recursos do Serviço de Aplicações com a CLI do Azure
  • Implementar uma API RESTful no Azure com o Git
  • Ativar o suporte para CORS no Serviço de Aplicações

Avançar para o próximo tutorial para saber como autenticar e autorizar utilizadores.

Tutorial: Autenticar e autorizar utilizadores ponto a ponto