IIS7 não está propagando autorização para subdiretórios

Question

Nosso aplicativo está usando autenticação de formulários e a solução está funcionando bem.

Recentemente, um dos nossos servidores de 2008 desenvolveu um problema em que a autorização não está sendo propagada para subdiretórios. Em outras palavras, no web.config principal, temos as seguintes configurações de autorização.

<authorization>
  <deny users="?" />
  <allow users="*" />
</authorization>

Isso faz com que um redirecionamento para a página de login para usuários não autenticados (bastante padrão).

As folhas de estilo estão no subdiretório / Content / Styles e o diretório Contents tem outro web.config que substitui a autorização com o seguinte:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.web>
        <authorization>
            <allow users="?" />
        </authorization>
    </system.web>
</configuration>

Isso deve permitir o acesso ao diretório stylesheets para usuários não autenticados (também bastante padronizados).

O problema é que as solicitações do servidor para folhas de estilo estão sendo redirecionadas para a página de login.

Eu tentei remover o site e os pools de aplicativos e recriá-los e também removi a função IIS do servidor, incluindo WAS (serviço de ativação do processo do Windows) e reinstalei. Nenhum destes resolveu o problema.

Eu sei que a configuração está correta porque eu posso pegar o mesmo aplicativo e soltá-lo em uma nova instalação do Server 2008 e ele funciona.

Alguma ideia de como posso resolver este problema sem ter de reconstruir toda a máquina?

    

Answer 1

Esse problema foi causado porque o diretório em que os arquivos estavam hospedados não estava acessível para a conta IUSR (apesar do fato de estar acessível para "NETWORK SERVICE" e a identidade do pool de aplicativos). Quando eu estava testando em uma instalação nova do IIS7, eu estava copiando a árvore de diretórios para \ inetpub \ wwwroot, onde IUSR já tinha acesso.

Ainda não está claro por que esse problema se exibiu como um redirecionamento para a página de login (como se ele não estivesse propiciando configurações de autorização corretamente), mas eu identifiquei alguns problemas com a configuração da autenticação de formulários.

Esta parte é crítica porque tudo o que encontrei não explica corretamente (ou adequadamente) isso.

Praticamente em todos os lugares que eu pesquisei, encontrei as seguintes configurações para web.config.

<configuration>
  <system.web>
    <authentication mode="Forms">
      <forms loginUrl="~/login.aspx" />
    </authentication>
    <authorization>
      <deny users="?" />
      <allow users="*" />
    </authorization>
  </system.web>
</configuration>

A maneira como isso é geralmente explicado é que esses usuários não autenticados são redirecionados para login.aspx e os usuários autenticados recebem acesso.

De fato, esta seção de configuração só se aplica a páginas ASP.NET (aspx). Qualquer outro tipo de conteúdo (html, asp, jpg, etc) não é governado por esta configuração.

Para proteger esses tipos de conteúdo, você deve ter "Autorização de URL do IIS 7" instalada e requer a seção web.config como mostrado abaixo.

<system.webServer>
  <security>
    <authorization>
      <clear />
      <add accessType="Deny" users="?" />
      <add accessType="Allow" users="*" />
    </authorization>
  </security>
</system.webServer>

Eu vi um lugar que explicava a diferença entre e como IIS6 vs IIS7, mas isso não é totalmente preciso. Existem diferentes mecanismos de autorização para diferentes tipos de conteúdo e você precisa de ambos para restringir o acesso a páginas não aspx.

    

Answer 2

Uma ideia vem à minha mente é que há outro arquivo web.config em sua subpasta "styles" que contém outra regra <deny users="?"> .

Existe uma discussão sobre o seguinte segmento de fóruns que poderia ser interersting para você: Problema com herança web.config e < autorização > seção .

Este artigo do MSDN contém uma frase interessante. Não sei como interpretá-lo:

Rules contained in application-level configuration files take precedence over inherited rules. The system determines which rule takes precedence by constructing a merged list of all rules for a URL, with the most recent rules (those nearest in the hierarchy) at the head of the list.