Principais diferenças entre o IIS e o ASP.NET Development Server (C#)

por Scott Mitchell

Baixar PDF

Ao testar um aplicativo ASP.NET localmente, é provável que você esteja usando o servidor Web de desenvolvimento ASP.NET. No entanto, o site de produção provavelmente tem o IIS habilitado. 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 é selecionada pelo software do servidor Web, que coordena com o runtime do 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 funcionalidade comum baseada 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 a instalação do IIS e a configuração correta.

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 em sistema de arquivos que não foram configurados para usar o IIS. Portanto, ao visitar qualquer 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 definições de configuração 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 do 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 erros, 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 servidor de desenvolvimento ASP.NET 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 de ASP.NET atendidas pelo servidor de desenvolvimento do ASP.NET terão os mesmos direitos de acesso que um administrador. No entanto, ASP.NET solicitações tratadas pelo IIS sã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 da Web possa ter configurado uma conta exclusiva para cada cliente. Além disso, seu provedor de host da Web provavelmente deu permissões limitadas a essa conta de computador. O resultado líquido é que você pode ter páginas da Web que são executadas sem erros 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 no disco que armazena a data e a hora mais recentes em 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 void  Page_Load(object sender, EventArgs e)

{

    string filePath =  Server.MapPath("~/LastTYASP35Access.txt");

    string contents =  string.Format("Last accessed on {0} by {1}",

        DateTime.Now.ToString(), Request.UserHostAddress);

    System.IO.File.WriteAllText(filePath,  contents);

}

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 Teach Yourself ASP.NET 3.5 in 24 Hours no ambiente de desenvolvimento usando o servidor de desenvolvimento ASP.NET. Supondo que você esteja conectado ao seu 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 em produção e visite a página de revisão do livro Teach Yourself ASP.NET 3.5 in 24 Horas hospedada. Neste ponto, você deve ver a página de revisão do livro normalmente ou a mensagem de erro mostrada na Figura 2. Alguns provedores de host da Web concedem permissões de gravação à conta de computador de ASP.NET anônima, nesse caso, a página funcionará sem erros. 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 o provedor de host da 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 de 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 na Web compartilhado, não leia ou escreva no Log de Eventos ou no Registro do Windows. Anote também as 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 é recebida 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 o IIS 7" neste tutorial para obter mais informações.)

O runtime do 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 ao 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 por usuários autenticados ou usuários que pertencem a uma determinada função.

Observação

Para um exame completo do ASP. Autenticação baseada em formulários do 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, esteja configurada para permitir apenas usuários autenticados. Imagine que essa pasta contenha ASP.NET páginas e arquivos PDF e que a intenção é que somente 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"?>
<?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 Web.config arquivo 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 para 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 do ASP.NET para o arquivo. O servidor de desenvolvimento do ASP.NET entrega a solicitação para o runtime do ASP.NET para processamento. Como ainda não fizemos logon e como o Web.config na PrivateDocs pasta está configurado para negar acesso anônimo, o runtime do ASP.NET nos redireciona automaticamente para a página Login.aspx de logon (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 pode 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 uma solicitação do IIS para o arquivo. Como um arquivo estático é solicitado, o IIS recupera e retorna o arquivo sem invocar o runtime do ASP.NET. Como resultado, não houve autorização de URL marcar executada; o conteúdo do PDF supostamente privado está acessível a qualquer pessoa que conheça a URL direta para o arquivo.

Figura 4: Os usuários anônimos podem baixar os arquivos PDF privados inserindo a URL direta para o 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 ASP.NET runtime. 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:

• Integração do ASP.NET com o IIS 7.0
• Usando ASP.NET autenticação de fóruns com todos os tipos de conteúdo no IIS 7 (vídeo)
• Servidores Web no Visual Web Developer

AnteriorAvançar