c# - extension - Path.GetTempFileName-El nombre del directorio no es válido
path gettempfilename with extension (5)
Al encontrarse con un problema donde en ciertos servidores obtenemos un error que el nombre del directorio no es válido cuando se usa Path.GetTempFileName. Investigaciones adicionales muestran que está intentando escribir un archivo en c: / Documents and Setting / computername / aspnet / local settings / temp (encontrado mediante Path.GetTempPath). Esta carpeta existe, así que supongo que debe tratarse de 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 / temporaryasp.net.
También me han dicho que este problema puede deberse al orden en que IIS y .NET estaban instalados en el servidor. He hecho el típico ''aspnet_regiis -i'' y comprobé la seguridad en las carpetas, etc. En este punto estoy atascado.
¿Alguien puede arrojar algo de luz sobre esto?
** Actualización: ** Resulta que proporcionar el acceso ''IUSR_ComputerName'' a la carpeta hace el truco. ¿Es ese el procedimiento correcto? No parece recordar haber hecho eso en el pasado, y obviamente, quiero seguir las mejores prácticas para mantener la seguridad. Esto es, después de todo, parte de un proceso de carga de archivos.
Puede usar Path.GetTempPath () para averiguar qué directorio está tratando de escribir.
Esta es probablemente una combinación de suplantación y una falta de coincidencia de los diferentes métodos de autenticación que se producen.
Hay muchas piezas; Trataré de revisarlos uno por uno.
La suplantación es una técnica para cambiar "temporalmente" la cuenta de usuario bajo la cual se está ejecutando un hilo. Básicamente, el hilo obtiene los mismos derechos y acceso, ni más ni menos, que la cuenta que se está suplantando. Tan pronto como el hilo termina de crear la página web, "vuelve" a la cuenta original y se prepara para la próxima llamada. Esta técnica se usa para acceder a recursos a los que solo tiene acceso el usuario que inició sesión en su sitio web. Mantenga el concepto por un minuto.
Ahora, de manera predeterminada, ASP.NET ejecuta un sitio web bajo 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í misma. Debe activarse intencionalmente en su web.config.
<identity impersonate="true" />
Si la configuración falta o está configurada como falsa, su código se ejecutará puro y simplemente bajo la cuenta de ASPNET mencionada anteriormente. Dado su mensaje de error, estoy seguro de que tiene la 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 vuelve suplantada ?
A menos que especifique la cuenta en el archivo web.config ( sintaxis completa del elemento de identidad aquí ), la cuenta suplantada es la que el 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 con pocos derechos 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 le está sucediendo a usted:
Su usuario está intentando acceder al sitio web e IIS no pudo autenticar a la persona por algún motivo. Debido a que el acceso anónimo está activado, (o no vería 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 suplanta a esta cuenta genérica IUSR___NombreDeEquipoComputador; solo que ahora el código no tiene acceso a las cosas a las que tuvo acceso la cuenta ASPNET, incluida su propia carpeta temporal.
Conceder IUSR_ComputerName ESCRIBIR el acceso a la carpeta hace que sus síntomas desaparezcan.
Pero eso solo los síntomas. Necesita revisar por qué la persona viene como "Anónimo / Invitado"?
Hay dos escenarios posibles:
a) Usted tenía la intención de usar IIS para la autenticación, pero la configuración de autenticación en IIS para algunos de sus servidores es incorrecta.
En ese caso, debe deshabilitar el acceso anónimo en esos servidores para que se produzcan los mecanismos de autenticación habituales. Tenga en cuenta que aún podría necesitar otorgar a sus usuarios acceso a esa carpeta temporal, o usar otra carpeta, una a la que sus usuarios ya tengan acceso.
He trabajado con este escenario muchas veces, y francamente te da menos dolores de cabeza para 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) No quería autenticar personas de todos modos, o quería usar Autenticación de formularios ASP.NET (que utiliza el acceso anónimo de IIS para omitir las comprobaciones en IIS y permite que ASP.NET maneje la autenticación directamente)
Este caso es un poco más complicado.
Debería ir a IIS y desactivar todas las formas de autenticación que no sean "Acceso anónimo". Tenga en cuenta que no puede hacer eso en el cuadro del desarrollador, porque el depurador necesita la autenticación integrada para habilitarse. Por lo tanto, su caja de depuración se comportará un poco diferente que el servidor real; Solo ten cuidado con eso.
Luego, debe decidir si debe desactivar la suplantación o, a la inversa, especificar la cuenta para suplantar en el archivo web.config. Haga lo primero si su servidor web no necesita recursos externos (como una base de datos). Haga lo segundo si su sitio web necesita ejecutarse bajo una cuenta que tenga acceso a una base de datos (u otro recurso externo).
Tiene dos alternativas más para especificar la cuenta para suplantar. Uno, podría ir a IIS y cambiar la cuenta "anónima" para que sea una con acceso al recurso en lugar de la que IIS administra para usted. La segunda alternativa es esconder 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!
Estaba teniendo el mismo problema con una de mis aplicaciones ASP.Net. Estaba obteniendo Path.GetTempPath () pero arrojaba una excepción de:
"No se pudo escribir en el archivo" C: / Windows / Temp / somefilename ", excepción: se deniega el acceso a la ruta" C: / Windows / Temp / somefilename ".
Intenté algunas sugerencias en esta página, pero nada me ayudó.
Al final, fui al servidor web (servidor IIS) y cambié los permisos en el directorio "C: / Windows / Temp" del servidor para otorgar permisos completos de lectura y escritura al usuario "Todos".
Y luego, finalmente, la excepción desapareció y mis usuarios pudieron descargar archivos de la aplicación. ¡Uf!
Encontré este error al diagnosticar una aplicación de consola que estaba escribiendo en archivos temporales. En una de mis iteraciones de prueba borré todos los archivos / directorios en temp para ejecutarlos ''clean-slate''. Resolví este problema autoinfligido al cerrar la sesión y volver a iniciarla.