ASP / ASP.NET A melhor maneira de lidar com permissões de gravação?

Question

Digamos que você tenha um aplicativo público ASP.NET (ou ASP clássico) no IIS com um script / página que precise gravar ou atualizar arquivos em uma pasta específica localizada na árvore de pastas de publicação na Web.

1) Qual é a maneira correta de configurar isso?

Minha maior preocupação é permitir que os aplicativos ASP / ASP.NET gravem em uma pasta, mas não quero que os usuários regulares de HTTP possam inserir arquivos nela.

    

Answer 1

Primeiro, deixe-me começar dizendo, eu sou um grande crente que quase sempre há uma solução melhor do que escrever coisas no disco. Seja escrevendo os dados em um banco de dados ou alimentando serviços da Web, escrever no disco deve ser a última opção. Dito isto, existem algumas razões válidas, mas isso é meio complicado e dependente do motivo pelo qual o aplicativo precisa gravar os arquivos.

Ter os dados gravados fora de onde o código está sendo executado é um requisito absoluto. Permitir que usuários finais gravem em um caminho onde os mecanismos ASPX / asp possam interpretar / executar código é ruim por razões óbvias.

Algumas outras coisas que afetam isso são:

1. Se você está executando o processo de trabalho em uma conta de domínio ou no serviço de rede padrão. É importante perceber que quando você conceder ao grupo IIS_WPG acesso de gravação a uma pasta, qualquer aplicativo ASP.NET em execução na conta padrão no servidor poderá gravar arquivos nessa pasta. Essa configuração é menos que ideal em servidores nos quais vários aplicativos são executados especialmente quando os aplicativos não são confiáveis e / ou estão sendo executados em um ambiente de hospedagem compartilhada / ISP.
2. Se os arquivos gerados precisam estar disponíveis na Web ou não. Se o seu aplicativo está apenas escrevendo alguns arquivos que não podem ser visualizados na web, basta criar o diretório, conceder os direitos e configurar o aplicativo para ler / gravar no local correto, tudo o que você precisa. Se o aplicativo precisar gravar arquivos visíveis na Web (isso é bastante comum em cenários de gerenciamento de conteúdo), você precisará criar um diretório virtual (sem direitos de execução de código / scripts) que mapeie para o seu diretório gravável.
3. Se você está ou não trabalhando em um ambiente de carga balanceada / web farm. Se o seu aplicativo estiver operando em um ambiente de criação e precisar gravar arquivos no disco por algum motivo, será apresentado um problema totalmente novo. Como você mantém arquivos gerados pelo usuário no webserver1 em sincronia com os arquivos gerados no webserver2? Fazê-lo através de algum script de sincronização complicado é doloroso na melhor das hipóteses e cheio de problemas de corrida / syncro. A melhor maneira de implementar isso é criar um compartilhamento em um terceiro servidor (idealmente um cluster com alguma redundância) e armazenar os dados nele. Se você estiver executando seus processos de trabalho em contas de domínio (Prática Recomendada de Segurança), poderá até mapear para o compartilhamento no aplicativo sem ter um usuário / passe em qualquer lugar no código ou web.config (deixa as pessoas de auditoria / segurança felizes). O IIS também tem a capacidade de mapear diretórios virtuais para caminhos UNC, portanto, isso não afetará sua capacidade de exibir esse conteúdo na Web.

Answer 2

A pasta App_Data

Para melhorar a segurança dos dados usados pelo aplicativo ASP.NET, uma nova subpasta denominada App_Data foi adicionada para aplicativos ASP.NET. Os arquivos armazenados na pasta App_Data não são retornados em resposta a solicitações HTTP diretas, o que torna a pasta App_Data o local recomendado para dados armazenados no aplicativo, incluindo .mdf (SQL Server Express Edition), .mdb (Microsoft Access) ou XML arquivos. Observe que, ao usar a pasta App_Data para armazenar os dados do seu aplicativo, a identidade do seu aplicativo tem permissões de leitura e gravação para a pasta App_Data.

O que há de novo no Acesso a Dados do ASP.NET

    

Answer 3

Provavelmente, apostar em stackoverflow.com ...

A melhor prática é colocar a pasta FORA da raiz do documento e fazer com que o aplicativo seja lido no sistema de arquivos. Caso contrário, torne a pasta somente leitura, exceto para o usuário do ASP [.NET] e controle os privilégios de gravação com as autorizações internas do aplicativo.

    

Answer 4

App_Data é, por padrão, gravável, mas não legível. O servidor parece resistir a qualquer tentativa de mudar isso. Assim, é melhor criar uma pasta completamente nova e alterar as permissões para NÃO EXECUTÁVEL, READÁVEL e POSTAL.