Principais diferenças entre o IIS e o ASP.NET Development Server (VB)
por Scott Mitchell
Ao testar um aplicativo ASP.NET localmente, as chances são de que você esteja usando o servidor Web de desenvolvimento ASP.NET. No entanto, o site de produção provavelmente é alimentado pelo IIS. Há algumas diferenças entre como esses servidores Web lidam com solicitações e essas diferenças podem ter consequências importantes. Este tutorial explora algumas das diferenças mais alemãs.
Introdução
Sempre que um usuário visita um aplicativo ASP.NET seu navegador envia uma solicitação para o site. Essa solicitação é coletada pelo software do servidor Web, que coordena com o runtime ASP.NET para gerar e retornar o conteúdo do recurso solicitado. Os dispositivos I nternet I nformation S (IIS) são um conjunto de serviços que fornecem funcionalidades comuns baseadas na Internet para servidores Windows. O IIS é o servidor Web mais usado para aplicativos ASP.NET em ambientes de produção; É mais provável que o software do servidor Web que está sendo usado pelo provedor de host da Web atenda ao seu aplicativo ASP.NET. O IIS também pode ser usado como o software do servidor Web no ambiente de desenvolvimento, embora isso inclua instalar o IIS e configurá-lo corretamente.
O servidor de desenvolvimento ASP.NET é uma opção de servidor Web alternativa para o ambiente de desenvolvimento; ele é fornecido com e é integrado ao Visual Studio. A menos que o aplicativo Web tenha sido configurado para usar o IIS, o servidor de desenvolvimento ASP.NET é iniciado automaticamente e usado como o servidor Web na primeira vez que você visita uma página da Web de dentro do Visual Studio. Os aplicativos Web de demonstração que criamos no tutorial Determinando quais arquivos precisam ser implantados eram aplicativos Web baseados no sistema de arquivos que não estavam configurados para usar o IIS. Portanto, ao visitar um desses sites de dentro do Visual Studio, o servidor de desenvolvimento ASP.NET é usado.
Em um mundo perfeito, os ambientes de desenvolvimento e produção seriam idênticos. No entanto, como discutimos no tutorial anterior, não é incomum que os ambientes tenham configurações diferentes. O uso de software de servidor Web diferente nos ambientes adiciona outra variável que deve ser levada em consideração ao implantar um aplicativo. Este tutorial aborda as principais diferenças entre o IIS e o servidor de desenvolvimento ASP.NET. Devido a essas diferenças, há cenários em que o código executado perfeitamente no ambiente de desenvolvimento gera uma exceção ou se comporta de forma diferente quando executado em produção.
Diferenças de contexto de segurança
Sempre que o software do servidor Web lida com uma solicitação de entrada, ele associa essa solicitação a um contexto de segurança específico. Essas informações de contexto de segurança são usadas pelo sistema operacional para determinar quais ações são permitidas pela solicitação. Por exemplo, uma página ASP.NET pode incluir código que registra alguma mensagem em um arquivo em disco. Para que essa página ASP.NET seja executada sem erro, o contexto de segurança deve ter as permissões apropriadas no nível do sistema de arquivos, ou seja, permissões de gravação nesse arquivo.
O ASP.NET Development Server associa solicitações de entrada ao contexto de segurança do usuário conectado no momento. Se você estiver conectado à área de trabalho como administrador, as páginas ASP.NET atendidas pelo servidor de desenvolvimento ASP.NET terão os mesmos direitos de acesso que um administrador. No entanto, ASP.NET solicitações tratadas pelo IIS estão associadas a uma conta de computador específica. Por padrão, a conta de computador do Serviço de Rede é usada pelas versões 6 e 7 do IIS, embora seu provedor de host web possa ter configurado uma conta exclusiva para cada cliente. Além disso, seu provedor de host web provavelmente deu permissões limitadas para essa conta de computador. O resultado líquido é que você pode ter páginas da Web que são executadas sem erro no ambiente de desenvolvimento, mas geram exceções relacionadas à autorização quando hospedadas no ambiente de produção.
Para mostrar esse tipo de erro em ação, criei uma página no site revisões de livros que cria um arquivo em disco que armazena a data e hora mais recentes que alguém visualizou a revisão Ensinar a Si mesmo ASP.NET 3,5 em 24 horas . Para acompanhar, abra a ~/Tech/TYASP35.aspx página e adicione o seguinte código ao Page_Load manipulador de eventos:
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
Dim filePath As String = Server.MapPath("~/LastTYASP35Access.txt")
Dim contents As String = String.Format("Last accessed on {0} by {1}", _
DateTime.Now.ToString(), Request.UserHostAddress)
System.IO.File.WriteAllText(filePath, contents)
End Sub
Observação
O File.WriteAllText método criará um novo arquivo se ele não existir e, em seguida, gravará o conteúdo especificado nele. Se o arquivo já existir, o conteúdo existente será substituído.
Em seguida, visite a página de revisão do livro ASP.NET 3.5 em 24 Horas no ambiente de desenvolvimento usando o servidor de desenvolvimento ASP.NET. Supondo que você esteja conectado ao computador com uma conta que tenha permissões adequadas para criar e modificar um arquivo de texto no diretório raiz do aplicativo Web, a revisão do livro aparece da mesma forma que antes, mas sempre que a página é visitada, a data e a hora e o LastTYASP35Access.txt endereço IP do usuário são armazenados no arquivo. Aponte seu navegador para este arquivo; você deverá ver uma mensagem semelhante à mostrada na Figura 1.
Figura 1: o arquivo de texto contém a última data e hora em que a revisão do livro foi visitada (clique para exibir a imagem em tamanho real)
Implante o aplicativo Web na produção e visite a página de revisão do livro Teach Yourself ASP.NET 3.5 em 24 Horas hospedada. Neste ponto, você deve ver a página de revisão do livro como normal ou a mensagem de erro mostrada na Figura 2. Alguns provedores de host da Web concedem permissões de gravação para a conta de computador ASP.NET anônima, nesse caso, a página funcionará sem erro. No entanto, se o provedor de host da Web proibir o acesso de gravação para a conta anônima, uma exceçãoUnauthorizedAccessException será gerada quando a TYASP35.aspx página tentar gravar a data e a hora atuais no LastTYASP35Access.txt arquivo.
Figura 2: a conta de computador padrão usada pelo IIS não tem permissões para gravar no sistema de arquivos (clique para exibir a imagem em tamanho real)
A boa notícia é que a maioria dos provedores de host da Web tem algum tipo de ferramenta de permissões que permite especificar permissões do sistema de arquivos em seu site. Conceda ao ASP.NET anônimo acesso de gravação da conta ao diretório raiz e, em seguida, reveja a página de revisão do livro. (Se necessário, entre em contato com seu provedor de host web para obter assistência sobre como conceder permissões de gravação à conta de ASP.NET padrão.) Desta vez, a página deve ser carregada sem erro e o LastTYASP35Access.txt arquivo deve ser criado com êxito.
A saída aqui é que, como o servidor de desenvolvimento do ASP.NET opera em um contexto de segurança diferente do IIS, é possível que suas páginas ASP.NET que leem ou gravam no sistema de arquivos, leiam ou gravam no Log de Eventos do Windows ou leiam ou gravam no Registro do Windows funcionem conforme o esperado no desenvolvimento, mas gerem exceções quando estiverem em produção. Ao criar um aplicativo Web que será implantado em um ambiente de hospedagem da Web compartilhado, não leia nem escreva no Log de Eventos ou no Registro do Windows. Anote também qualquer ASP.NET páginas que leem ou gravam no sistema de arquivos, pois talvez seja necessário conceder privilégios de leitura e gravação nas pastas apropriadas no ambiente de produção.
Diferenças no fornecimento de conteúdo estático
Outra diferença central entre o IIS e o servidor de desenvolvimento ASP.NET é como eles lidam com solicitações de conteúdo estático. Cada solicitação que entra no servidor de desenvolvimento ASP.NET, seja para uma página ASP.NET, uma imagem ou um arquivo JavaScript, é processada pelo runtime do ASP.NET. Por padrão, o IIS invoca apenas o runtime do ASP.NET quando uma solicitação entra para um recurso de ASP.NET, como uma página da Web ASP.NET, um serviço Web e assim por diante. As solicitações de conteúdo estático – imagens, arquivos CSS, arquivos JavaScript, arquivos PDF, arquivos ZIP e similares – são recuperadas pelo IIS sem o envolvimento do runtime do ASP.NET. (É possível instruir o IIS a trabalhar com o runtime do ASP.NET ao fornecer conteúdo estático; consulte a seção "Executando autenticação Forms-Based e autenticação de URL em arquivos estáticos com IIS 7" neste tutorial para obter mais informações.)
O runtime ASP.NET executa várias etapas para gerar o conteúdo solicitado, incluindo autenticação (identificando o solicitante) e autorização (determinando se o solicitante tem permissão para exibir o conteúdo solicitado). Uma forma popular de autenticação é a autenticação baseada em formulários, na qual um usuário é identificado inserindo suas credenciais - geralmente um nome de usuário e senha - em caixas de texto em uma página da Web. Ao validar suas credenciais, o site armazena um cookie de tíquete de autenticação no navegador do usuário, que é enviado a cada solicitação subsequente para o site e é o que é usado para autenticar o usuário. Além disso, é possível especificar regras de autorização de URL que determinam o que os usuários podem ou não acessar uma pasta específica. Muitos sites ASP.NET usam autenticação baseada em formulários e autorização de URL para dar suporte a contas de usuário e definir partes do site que só podem ser acessadas para usuários autenticados ou usuários que pertencem a uma determinada função.
Observação
Para um exame detalhado do ASP. Autenticação baseada em formulários da NET, autorização de URL e outros recursos relacionados à conta de usuário, certifique-se de marcar meus Tutoriais de Segurança do Site.
Considere um site que dá suporte a contas de usuário usando autorização baseada em formulários e tenha uma pasta que, usando a autorização de URL, seja configurada para permitir apenas usuários autenticados. Imagine que essa pasta contém ASP.NET páginas e arquivos PDF e que a intenção é que apenas usuários autenticados possam exibir esses arquivos PDF.
O que acontece se um visitante tentar exibir um desses arquivos PDF inserindo a URL diretamente na barra de Endereços do navegador? Para descobrir, vamos criar uma nova pasta no site Revisões de Livros, adicionar alguns arquivos PDF e configurar o site para usar a autorização de URL para proibir que usuários anônimos acessem essa pasta. Se você baixar o aplicativo de demonstração, verá que criei uma pasta chamada PrivateDocs e adicionei um PDF de meus Tutoriais de Segurança do Site (como ajustar!). A PrivateDocs pasta também contém um Web.config arquivo que especifica as regras de autorização de URL para negar usuários anônimos:
<?xml version="1.0"?>
<configuration>
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
Por fim, configurei o aplicativo Web para usar a autenticação baseada em formulários atualizando o arquivo Web.config no diretório raiz, substituindo:
<authentication mode="Windows" />
Com:
<authentication mode="Forms" />
Usando o servidor de desenvolvimento ASP.NET, visite o site e insira a URL direta em um dos arquivos PDF na barra de endereços do navegador. Se você baixou o site associado a este tutorial, a URL deverá ser semelhante a: http://localhost:portNumber/PrivateDocs/aspnet_tutorial01_Basics_vb.pdf
Inserir essa URL na barra De endereços faz com que o navegador envie uma solicitação para o servidor de desenvolvimento ASP.NET para o arquivo. O servidor de desenvolvimento ASP.NET entrega a solicitação para o runtime ASP.NET para processamento. Como ainda não fizemos logon e, como a Web.configPrivateDocs na pasta está configurada para negar acesso anônimo, o runtime do ASP.NET nos redireciona automaticamente para a página de logon ( Login.aspx consulte a Figura 3). Ao redirecionar o usuário para a página de logon, ASP.NET inclui um ReturnUrl parâmetro querystring que indica a página que o usuário estava tentando exibir. Depois de fazer logon com êxito, o usuário poderá retornar a esta página.
Figura 3: Usuários não autorizados são redirecionados automaticamente para a página de logon (clique para exibir a imagem em tamanho real)
Agora vamos ver como isso se comporta na produção. Implante seu aplicativo e insira a URL direta em um dos PDFs na PrivateDocs pasta em produção. Isso solicita que o navegador envie um IIS de solicitação para o arquivo. Como um arquivo estático é solicitado, o IIS recupera e retorna o arquivo sem invocar o runtime ASP.NET. Como resultado, não houve nenhuma autorização de URL marcar executada; o conteúdo do PDF supostamente privado é acessível a qualquer pessoa que conheça a URL direta para o arquivo.
Figura 4: usuários anônimos podem baixar os arquivos PDF privados inserindo a URL direta no arquivo (clique para exibir a imagem em tamanho real)
Executando autenticação Forms-Based e autenticação de URL em arquivos estáticos com o IIS 7
Há algumas técnicas que você pode usar para proteger o conteúdo estático de usuários não autorizados. O IIS 7 introduziu o pipeline integrado, que casa o fluxo de trabalho do IIS com o fluxo de trabalho do runtime do ASP.NET. Em poucas palavras, você pode instruir o IIS a invocar os módulos de autenticação e autorização do runtime ASP.NET todas as solicitações de entrada (incluindo conteúdo estático, como arquivos PDF). Entre em contato com seu provedor de host da Web para descobrir como configurar seu site para usar o pipeline integrado.
Depois que o IIS tiver sido configurado para usar o pipeline integrado, adicione a seguinte marcação ao Web.config arquivo no diretório raiz:
<system.webServer>
<modules>
<add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
</modules>
</system.webServer>
Essa marcação instrui o IIS 7 a usar os módulos de autenticação e autorização baseados em ASP.NET. Implante novamente seu aplicativo e visite novamente o arquivo PDF. Desta vez, quando o IIS lida com a solicitação, ele dá ao ASP.NET a lógica de autenticação e autorização do runtime uma oportunidade de inspecionar a solicitação. Como somente os usuários autenticados estão autorizados a exibir o conteúdo na PrivateDocs pasta, o visitante anônimo é redirecionado automaticamente para a página de logon (consulte a Figura 3).
Observação
Se o provedor de host da Web ainda estiver usando o IIS 6, você não poderá usar o recurso de pipeline integrado. Uma solução alternativa é colocar seus documentos particulares em uma pasta que proíba o acesso HTTP (como App_Data) e, em seguida, criar uma página para atender a esses documentos. Essa página pode ser chamada GetPDF.aspxde e é passada o nome do PDF por meio de um parâmetro querystring. A GetPDF.aspx página primeiro verificaria se o usuário tem permissão para exibir o arquivo e, nesse caso, usaria o Response.WriteFile(filePath) método para enviar o conteúdo do arquivo PDF solicitado de volta para o cliente solicitante. Essa técnica também funcionaria para o IIS 7 se você não quisesse habilitar o pipeline integrado.
Resumo
Os aplicativos Web em um ambiente de produção são hospedados usando o software do servidor Web do IIS da Microsoft. No ambiente de desenvolvimento, no entanto, o aplicativo pode ser hospedado usando o IIS ou o servidor de desenvolvimento ASP.NET. Idealmente, o mesmo software de servidor Web deve ser usado em ambos os ambientes porque o uso de software diferente adiciona outra variável na combinação. No entanto, a facilidade de uso do servidor de desenvolvimento ASP.NET o torna uma opção atraente no ambiente de desenvolvimento. A boa notícia é que há apenas algumas diferenças fundamentais entre o IIS e o servidor de desenvolvimento ASP.NET e, se você estiver ciente dessas diferenças, poderá tomar medidas para ajudar a garantir que o aplicativo funcione e funcione da mesma maneira, independentemente do ambiente.
Programação feliz!
Leitura Adicional
Para obter mais informações sobre os tópicos discutidos neste tutorial, consulte os seguintes recursos:
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de