Como proteger arquivos estáticos com a autenticação de formulário do ASP.NET no IIS 7.5?

Eu tenho um site em execução em um servidor IIS 7.5 com o ASP.NET 4.0 em um host compartilhado, mas com total confiança.

O site é um “navegador de arquivos” básico que permite que os visitantes façam login e tenham uma lista de arquivos disponíveis para eles exibidos e, obviamente, baixam os arquivos. Os arquivos estáticos (principalmente arquivos pdf) estão localizados em uma subpasta do site chamada dados, por exemplo, http://example.com/data/ …

O site usa a autenticação de formulário do ASP.NET.

Minha pergunta é: Como faço para que o mecanismo do ASP.NET manipule as solicitações para os arquivos estáticos na pasta de dados, para que a solicitação de arquivos seja autenticada pelo ASP.NET e os usuários não consigam vincular profundamente a um arquivo e pegar arquivos que não podem ter?

Atenciosamente, Egil.

Se o pool de aplicativos estiver sendo executado no modo Integrado, você poderá fazer o seguinte.

Adicione o seguinte ao seu web.config de nível superior.

         

Agora você pode usar as permissions padrão do ASP.NET em seu web.config para forçar a autenticação de formulários para todos os arquivos no diretório.

       

Eu tive o mesmo problema em conseguir papéis para autenticar. Por tentativa e erro, finalmente consegui que funcionasse com uma pequena edição do código do @Joel Cunningham:

  

Eu usei estes dois sites como referências: http://forums.iis.net/t/1177964.aspx e http://learn.iis.net/page.aspx/244/how-to-take-advantage-of-of- o-ii-integrado-pipeline /

Este é um tópico antigo, mas aconteceu e ocorreu o mesmo problema que o Egil. Aqui está a versão da correção de Joel que inclui papéis:

           

Eu queria saber por que seria necessário adicionar novamente módulos (com opções padrão) que são adicionados por padrão para o Pipeline Integrado, então eu cavei um pouco mais fundo.

Você precisa remover e adicionar novamente os módulos porque, por padrão, os módulos não são adicionados com as opções padrão. Eles têm uma pré-condição adicionada para compatibilidade com versões anteriores para serem executados apenas para conteúdo manipulado por um manipulador ASP.NET registrado (por exemplo, páginas .aspx).

O padrão é assim:

  

Ao remover os módulos e adicioná-los novamente sem uma pré-condição, esses módulos individuais são executados para cada solicitação (incluindo seu conteúdo estático). É mais granular do que ativar o runAllManagedModulesForAllRequests .

Você pode ler sobre isso em alguns artigos de quando o Pipeline Integrado foi introduzido com o IIS 7:

  • Integração ASP.NET com o IIS 7
  • Como tirar proveito do pipeline integrado do IIS 7.0

Observe que há um erro de digitação ou o nome do módulo no segundo artigo (e a resposta de @ João) foi alterado de FormsAuthenticationModule para FormsAuthentication em algum momento.

O conjunto de módulos de trabalho do IIS 7.5 até o 8.5 parece assim para mim:

              

Termo aditivo:

Como @eych observou, isso também bloqueia o access à pasta ~/Content (ou onde quer que você tenha seu CSS), e ~/Scripts , e assim por diante.

Se você quiser permitir exceções – ou seja, permitir que certos arquivos / pastas sejam acessados ​​por usuários não autenticados – você pode fazer isso por meio do elemento location . Adicione o seguinte ao web.config :

         

Atualização: Uma solução melhor é deixar o access ativado por padrão – o que permitirá access ao seu CSS / JavaScript / etc. – e aplicar o “bloqueio” (somente) à pasta onde o conteúdo estático está armazenado:

        

Advertência: no nosso caso (um site MVC), precisávamos decorar todas as nossas ações de controlador (exceto login) com [AuthorizeAttribute] . O que é uma boa ideia de qualquer maneira, mas que anteriormente não era necessário (porque anteriormente qualquer solicitação não autorizada foi redirecionada para a página de login).

Se o pool de aplicativos estiver sendo executado no modo Clássico, você poderá fazer o seguinte. Você precisará repetir essas etapas para cada extensão de arquivo que deseja manipular, mas estou usando o .html aqui.

Primeiro, adicione um provedor de criação de página ao Web.config:

           

Em seguida, adicione uma fábrica de manipuladores de páginas:

         

Em seguida, adicione um manipulador de páginas:

          

Isso funcionou para mim. (Crédito: http://www.ifinity.com.au/Blog/EntryId/66/How-To-301-Redirect-htm-or-html-pages-to-DotNetNuke-aspx-pages .)