Path.GetTempFileName: el nombre del directorio no es válido
https://stackoverflow.com/questions/55411
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Nos encontramos con un problema en el que en ciertos servidores recibimos un error que indica que el nombre del directorio no es válido cuando usamos Path.GetTempFileName.Una investigación más profunda muestra que está intentando escribir un archivo en c:\Documents and Settings\computername\aspnet\local settings emp (encontrado usando Path.GetTempPath).Esta carpeta existe, así que supongo que debe ser un problema de permisos con respecto a la cuenta asp.net.
Algunos me han dicho que Path.GetTempFileName debería apuntar a los archivos C:\Windows\Microsoft.NET\Framework\v2.0.50727 emporaryasp.net.
También me dijeron que este problema puede deberse al orden en que se instalaron IIS y .NET en el servidor.Hice el típico 'aspnet_regiis -i' y verifiqué la seguridad en las carpetas, etc.En este punto estoy estancado.
¿Alguien puede arrojar algo de luz sobre esto?
**Actualización:**Resulta que proporcionar acceso 'IUSR_ComputerName' a la carpeta es suficiente.¿Es ese el procedimiento correcto?No creo recordar haber hecho eso en el pasado y, obviamente, quiero seguir las mejores prácticas para mantener la seguridad.Después de todo, esto es parte del proceso de carga de archivos.
Solución
Probablemente se trate de una combinación de suplantación de identidad y una discrepancia entre los diferentes métodos de autenticación.
Hay muchas piezas;Intentaré repasarlos uno por uno.
Interpretación es una técnica para cambiar "temporalmente" la cuenta de usuario bajo la cual se ejecuta un hilo.Básicamente, el hilo obtiene brevemente los mismos derechos y acceso (ni más ni menos) que la cuenta que está siendo suplantada.Tan pronto como el hilo termina de crear la página web, "vuelve" a la cuenta original y se prepara para la siguiente llamada.Esta técnica se utiliza para acceder a recursos a los que solo tiene acceso el usuario que inició sesión en su sitio web.Mantén el concepto por un minuto.
Ahora, de forma predeterminada, ASP.NET ejecuta un sitio web con una cuenta local llamada ASPNET.Nuevamente, de manera predeterminada, solo la cuenta ASPNET y los miembros del grupo Administradores pueden escribir en esa carpeta.Su carpeta temporal está bajo el ámbito de esa cuenta.Esta es la segunda pieza del rompecabezas.
La suplantación no ocurre por sí sola.Debe activarse intencionalmente en su web.config.
<identity impersonate="true" />
Si falta la configuración o se establece en falsa, su código se ejecutará pura y simplemente en la cuenta ASPNET mencionada anteriormente.Dado su mensaje de error, estoy seguro de que tiene suplantación = verdadero.¡No hay nada de malo en ello!La suplantación tiene ventajas y desventajas que van más allá de esta discusión.
Queda una pregunta:cuando usas la suplantación, qué cuenta se suplanta?
A menos que especifique la cuenta en web.config (sintaxis completa del elemento de identidad aquí), la cuenta suplantada es la que IIS entregó a ASP.NET.Y eso depende de cómo el usuario se haya autenticado (o no) en el sitio.Esa es tu tercera y última pieza.
La cuenta IUSR_ComputerName es una cuenta de derechos bajos creada por IIS.De forma predeterminada, esta cuenta es la cuenta bajo la cual se ejecuta una llamada web. si el usuario no pudo ser autenticado.Es decir, el usuario entra como "anónimo".
En resumen, esto es lo que te está pasando:
Su usuario está intentando acceder al sitio web y IIS no pudo autenticar a la persona por algún motivo.Debido a que el acceso anónimo está activado (o no verá IUSRComputerName accediendo a la carpeta temporal), IIS permite al usuario de todos modos, pero como un usuario genérico.Su código ASP.NET se ejecuta y se hace pasar por esta cuenta "invitada" genérica IUSR___ComputerName;sólo que ahora el código no tiene acceso a las cosas a las que tenía acceso la cuenta ASPNET, incluida su propia carpeta temporal.
Otorgar acceso de ESCRITURA a IUSR_ComputerName a la carpeta hace que sus síntomas desaparezcan.
Pero esos son sólo los síntomas.Necesitas revisar ¿Por qué la persona viene como "Anónimo/Invitado"?
Hay dos escenarios probables:
a) Tenía la intención de utilizar IIS para la autenticación, pero la configuración de autenticación en IIS para algunos de sus servidores es incorrecta.
En ese caso, deberá desactivar el acceso anónimo en esos servidores para que se realicen los mecanismos de autenticación habituales.Tenga en cuenta que es posible que aún deba otorgar a sus usuarios acceso a esa carpeta temporal, o usar otra carpeta en su lugar, una a la que sus usuarios ya tengan acceso.
He trabajado con este escenario muchas veces y, francamente, te da menos dolores de cabeza renunciar a la carpeta Temp;cree una carpeta dedicada en el servidor, establezca los permisos adecuados y establezca su ubicación en web.config.
b) De todos modos, no quería autenticar a las personas, o quería usar la autenticación de formularios ASP.NET (que utiliza el acceso anónimo de IIS para evitar las comprobaciones en IIS y permite que ASP.NET maneje la autenticación directamente)
Este caso es un poco más complicado.
Debe ir a IIS y desactivar todas las formas de autenticación que no sean el "Acceso anónimo".Tenga en cuenta que no puede hacer eso en el cuadro del desarrollador, porque el depurador necesita que la autenticación integrada esté habilitada.Entonces su cuadro de depuración se comportará un poco diferente al servidor real;Solo ten cuidado con eso.
Luego, debe decidir si debe desactivar la suplantación o, por el contrario, especificar la cuenta para suplantar en web.config.Haga lo primero si su servidor web no necesita recursos externos (como una base de datos).Haga esto último si su sitio web necesita ejecutarse con una cuenta que tenga acceso a una base de datos (o algún otro recurso externo).
Tienes dos alternativas más para especificar la cuenta a suplantar.Primero, puede ir a IIS y cambiar la cuenta "anónima" para que tenga acceso al recurso en lugar de la que IIS administra por usted.La segunda alternativa es ocultar la cuenta y la contraseña cifradas en el registro.Ese paso es un poco complicado y también va más allá del alcance de esta discusión.
¡Buena suerte!
Otros consejos
Encontré este error al diagnosticar una aplicación de consola que estaba escribiendo en archivos temporales.En una de mis iteraciones de prueba, eliminé todos los archivos/directorios en temporal para una ejecución "limpia".Resolví este problema autoinfligido cerrando sesión y volviendo a iniciarla.
Puedes usar Ruta.GetTempPath() para saber en qué directorio está intentando escribir.
Estaba teniendo el mismo problema con una de mis aplicaciones ASP.Net.Estuve obteniendo Ruta.GetTempPath() pero estaba lanzando una excepción de:
"No se pudo escribir en el archivo "C:\Windows emp\somefilename", excepción:Se deniega el acceso a la ruta "C:\Windows emp\somefilename".
Probé algunas sugerencias en esta página, pero nada ayudó.
Al final, fui al servidor web (servidor IIS) y cambié los permisos en el directorio "C:\Windows emp" del servidor para darle al usuario "Todos" permisos completos de lectura y escritura.
Y finalmente, la excepción desapareció y mis usuarios pudieron descargar archivos de la aplicación.¡Uf!
