Path.GetTempFileName — O nome do diretório é inválido

Question

Encontramos um problema em que, em determinados servidores, obtemos um erro informando que o nome do diretório é inválido ao usar Path.GetTempFileName.Uma investigação mais aprofundada mostra que ele está tentando gravar um arquivo em c:\Documents and Setting\computername\aspnet\local settings emp (encontrado usando Path.GetTempPath).Esta pasta existe, então presumo que seja um problema de permissão em relação à conta asp.net.

Alguns me disseram que Path.GetTempFileName deveria estar apontando para arquivos C:\Windows\Microsoft.NET\Framework\v2.0.50727 emporaryasp.net.

Também me disseram que esse problema pode ser devido à ordem em que o IIS e o .NET foram instalados no servidor.Eu fiz o típico 'aspnet_regiis -i' e verifiquei a segurança nas pastas, etc.Neste ponto estou preso.

Alguém pode lançar alguma luz sobre isso?

**Atualização:**Acontece que fornecer acesso 'IUSR_ComputerName' à pasta resolve.Esse é o procedimento correto?Não me lembro de ter feito isso no passado e, obviamente, quero seguir as práticas recomendadas para manter a segurança.Afinal, isso faz parte de um processo de upload de arquivo.

Answer 1

Esta é provavelmente uma combinação de representação e uma incompatibilidade de diferentes métodos de autenticação.

São muitas peças;Vou tentar examiná-los um por um.

Representação é uma técnica para alternar "temporariamente" a conta do usuário sob a qual um thread está sendo executado.Essencialmente, o tópico ganha brevemente os mesmos direitos e acesso – nem mais, nem menos – que a conta que está sendo personificada.Assim que o thread termina de criar a página da web, ele "reverte" para a conta original e fica pronto para a próxima chamada.Esta técnica é usada para acessar recursos aos quais somente o usuário logado em seu site tem acesso.Segure o conceito por um minuto.

Agora, por padrão, o ASP.NET executa um site em uma conta local chamada ASPNET.Novamente, por padrão, somente a conta ASPNET e os membros do grupo Administradores podem gravar nessa pasta.Sua pasta temporária está sob a alçada dessa conta.Esta é a segunda peça do quebra-cabeça.

A personificação não acontece por si só.Ele precisa ser ativado intencionalmente em seu web.config.

<identity impersonate="true" />

Se a configuração estiver ausente ou definida como falsa, seu código será executado pura e simplesmente na conta ASPNET mencionada acima.Dada a sua mensagem de erro, tenho certeza de que você tem personificação=true.Não há nada de errado com isso!A personificação tem vantagens e desvantagens que vão além desta discussão.

Resta uma pergunta:quando você usa personificação, qual conta é personificada?

A menos que você especifique a conta no web.config (sintaxe completa do elemento de identidade aqui), a conta representada será aquela que o IIS entregou ao ASP.NET.E isso depende de como o usuário se autenticou (ou não) no site.Essa é a sua terceira e última peça.

A conta IUSR_ComputerName é uma conta com direitos reduzidos criada pelo IIS.Por padrão, esta conta é a conta sob a qual uma chamada web é executada se o usuário não puder ser autenticado.Ou seja, o usuário entra como “anônimo”.

Em resumo, isso é o que está acontecendo com você:

Seu usuário está tentando acessar o site e o IIS não conseguiu autenticar a pessoa por algum motivo.Como o acesso anônimo está ativado (ou você não veria IUSRComputerName acessando a pasta temporária), o IIS permite o usuário de qualquer maneira, mas como um usuário genérico.Seu código ASP.NET é executado e representa essa conta genérica de "convidado" IUSR___ComputerName;só que agora o código não tem acesso às coisas que a conta ASPNET tinha acesso, incluindo sua própria pasta temporária.

Conceder acesso IUSR_ComputerName WRITE à pasta faz com que seus sintomas desapareçam.

Mas isso são apenas os sintomas.Você precisa revisar por que a pessoa vem como "Anônimo/Convidado"?

Existem dois cenários prováveis:

a) Você pretendia usar o IIS para autenticação, mas as configurações de autenticação no IIS para alguns dos seus servidores estão erradas.

Nesse caso, é necessário desabilitar o acesso Anônimo nesses servidores para que os mecanismos usuais de autenticação ocorram.Observe que talvez você ainda precise conceder aos usuários acesso a essa pasta temporária ou usar outra pasta, uma à qual os usuários já tenham acesso.

Já trabalhei com esse cenário muitas vezes e, francamente, dá menos dor de cabeça abrir mão da pasta Temp;crie uma pasta dedicada no servidor, defina as permissões adequadas e defina sua localização em web.config.

b) Você não queria autenticar pessoas de qualquer maneira ou queria usar a autenticação de formulários ASP.NET (que usa o acesso anônimo do IIS para ignorar verificações no IIS e permite que o ASP.NET lide com a autenticação diretamente)

Este caso é um pouco mais complicado.

Você deve ir ao IIS e desabilitar todas as formas de autenticação exceto "Acesso Anônimo".Observe que você não pode fazer isso na caixa do desenvolvedor, porque o depurador precisa que a Autenticação Integrada esteja habilitada.Portanto, sua caixa de depuração se comportará de maneira um pouco diferente do servidor real;apenas esteja ciente disso.

Em seguida, você precisa decidir se deve desativar a representação ou, inversamente, especificar a conta a ser representada no web.config.Faça o primeiro se o seu servidor web não precisar de recursos externos (como um banco de dados).Faça o último caso o seu site precise ser executado em uma conta que tenha acesso a um banco de dados (ou algum outro recurso externo).

Você tem mais duas alternativas para especificar a conta a ser representada.Primeiro, você pode ir ao IIS e alterar a conta "anônima" para uma com acesso ao recurso, em vez daquela que o IIS gerencia para você.A segunda alternativa é armazenar a conta e a senha criptografadas no registro.Essa etapa é um pouco complicada e também vai além do escopo desta discussão.

Boa sorte!

Answer 2

Poderia ser porque IIS_WPG não tem acesso a uma pasta temporária.Se você acha que é um problema de permissão, execute um Procmon no processo de trabalho do asp.net e verifique se há erros de AccessDenied.

Answer 3

Encontrei esse erro ao diagnosticar um aplicativo de console que estava gravando em arquivos temporários.Em uma de minhas iterações de teste, limpei todos os arquivos/diretórios temporários para uma execução 'limpa'.Resolvi esse problema autoinfligido saindo e entrando novamente.

Answer 4

Você pode usar Path.GetTempPath() para descobrir em qual diretório ele está tentando gravar.

Answer 5

Eu estava tendo o mesmo problema com um dos meus aplicativos ASP.Net.eu estava conseguindo Path.GetTempPath() mas estava lançando uma exceção de:

"Não foi possível gravar no arquivo "C:\Windows emp\somefilename", exceção:O acesso ao caminho "C:\Windows emp\somefilename" foi negado."

Tentei algumas sugestões nesta página, mas nada ajudou.

No final, entrei no servidor web (servidor IIS) e alterei as permissões no diretório "C:\Windows emp" do servidor para conceder ao usuário "Todos" permissões completas de leitura e gravação.

E então, finalmente, a exceção desapareceu e meus usuários puderam baixar arquivos do aplicativo.Ufa!