Path.GetTempFileName — Le nom du répertoire n'est pas valide

Question

Nous rencontrons un problème où, sur certains serveurs, nous obtenons une erreur indiquant que le nom du répertoire n'est pas valide lors de l'utilisation de Path.GetTempFileName.Une enquête plus approfondie montre qu'il tente d'écrire un fichier dans c:\Documents and Setting\computername\aspnet\local settings emp (trouvé à l'aide de Path.GetTempPath).Ce dossier existe, donc je suppose qu'il doit s'agir d'un problème d'autorisations concernant le compte asp.net.

Certains m'ont dit que Path.GetTempFileName devrait pointer vers les fichiers C:\Windows\Microsoft.NET\Framework\v2.0.50727 emporaryasp.net.

On m'a également dit que ce problème pouvait être dû à l'ordre dans lequel IIS et .NET étaient installés sur le serveur.J'ai fait le typique 'aspnet_regiis -i' et vérifié la sécurité des dossiers, etc.À ce stade, je suis coincé.

Quelqu'un peut-il faire la lumière à ce sujet ?

**Mise à jour :**Il s'avère que fournir l'accès « IUSR_ComputerName » au dossier fait l'affaire.Est-ce la bonne procédure ?Je ne me souviens pas avoir fait cela dans le passé et je souhaite évidemment suivre les meilleures pratiques pour maintenir la sécurité.Après tout, cela fait partie du processus de téléchargement de fichiers.

Answer 1

Il s’agit probablement d’une combinaison d’usurpation d’identité et d’une inadéquation des différentes méthodes d’authentification.

Il existe de nombreuses pièces ;Je vais essayer de les parcourir un par un.

Imitation est une technique permettant de changer "temporairement" le compte utilisateur sous lequel un thread est en cours d'exécution.Essentiellement, le fil de discussion obtient brièvement les mêmes droits et accès – ni plus, ni moins – que le compte dont l'identité est usurpée.Dès que le fil de discussion a fini de créer la page Web, il « revient » au compte d'origine et se prépare pour le prochain appel.Cette technique est utilisée pour accéder à des ressources auxquelles seul l'utilisateur connecté à votre site Web a accès.Conservez le concept pendant une minute.

Désormais, par défaut, ASP.NET exécute un site Web sous un compte local appelé RÉSEAUASP.Encore une fois, par défaut, seuls le compte ASPNET et les membres du groupe Administrateurs peuvent écrire dans ce dossier.Votre dossier temporaire relève de la compétence de ce compte.C'est la deuxième pièce du puzzle.

L'usurpation d'identité ne se produit pas d'elle-même.Il doit être activé intentionnellement dans votre web.config.

<identity impersonate="true" />

Si le paramètre est manquant ou défini sur false, votre code s'exécutera purement et simplement sous le compte ASPNET mentionné ci-dessus.Compte tenu de votre message d'erreur, je suis sûr que vous avez impersonation=true.Il n'y a rien de mal à cela!L'usurpation d'identité présente des avantages et des inconvénients qui vont au-delà de cette discussion.

Il reste une question :lorsque vous utilisez l'usurpation d'identité, quel compte est usurpé?

Sauf si vous spécifiez le compte dans le web.config (syntaxe complète de l'élément d'identité ici), le compte emprunté est celui que l'IIS a transmis à ASP.NET.Et cela dépend de la manière dont l'utilisateur s'est authentifié (ou non) sur le site.C'est votre troisième et dernière pièce.

Le compte IUSR_ComputerName est un compte à faibles droits créé par IIS.Par défaut, ce compte est le compte sous lequel un appel Web est exécuté si l'utilisateur n'a pas pu être authentifié.Autrement dit, l'utilisateur apparaît comme un « anonyme ».

En résumé, voici ce qui vous arrive :

Votre utilisateur tente d'accéder au site Web et IIS n'a pas pu authentifier la personne pour une raison quelconque.Étant donné que l'accès anonyme est activé (sinon vous ne verriez pas IUSRComputerName accéder au dossier temporaire), IIS autorise l'utilisateur de toute façon, mais en tant qu'utilisateur générique.Votre code ASP.NET s’exécute et emprunte l’identité de ce compte « invité » générique IUSR___ComputerName ;seulement maintenant, le code n'a pas accès aux éléments auxquels le compte ASPNET avait accès, y compris son propre dossier temporaire.

Accorder à IUSR_ComputerName l'accès en écriture au dossier fait disparaître vos symptômes.

Mais ce ne sont que les symptômes.Vous devez revoir pourquoi la personne vient-elle en tant qu'"Anonyme/Invité" ?

Il existe deux scénarios probables :

a) Vous aviez l'intention d'utiliser IIS pour l'authentification, mais les paramètres d'authentification dans IIS pour certains de vos serveurs sont erronés.

Dans ce cas, vous devez désactiver l'accès anonyme sur ces serveurs afin que les mécanismes d'authentification habituels aient lieu.Notez que vous devrez peut-être toujours accorder à vos utilisateurs l'accès à ce dossier temporaire, ou utiliser un autre dossier à la place, auquel vos utilisateurs ont déjà accès.

J'ai travaillé avec ce scénario à plusieurs reprises, et franchement, cela vous donne moins de maux de tête de renoncer au dossier Temp ;créez un dossier dédié sur le serveur, définissez les autorisations appropriées et définissez son emplacement dans web.config.

b) De toute façon, vous ne vouliez pas authentifier les personnes ou vous vouliez utiliser l'authentification par formulaires ASP.NET (qui utilise l'accès anonyme d'IIS pour contourner les contrôles dans IIS et permet à ASP.NET de gérer directement l'authentification)

Ce cas est un peu plus compliqué.

Vous devez accéder à IIS et désactiver toutes les formes d'authentification autres que « Accès anonyme ».Notez que vous ne pouvez pas faire cela dans la boîte du développeur, car le débogueur a besoin que l'authentification intégrée soit activée.Ainsi, votre boîte de débogage se comportera un peu différemment du vrai serveur ;Soit juste avertit de cela.

Ensuite, vous devez décider si vous devez désactiver l'usurpation d'identité ou, à l'inverse, spécifier le compte à emprunter dans le fichier web.config.Faites la première si votre serveur Web n'a pas besoin de ressources extérieures (comme une base de données).Effectuez cette dernière solution si votre site Web doit être exécuté sous un compte ayant accès à une base de données (ou à une autre ressource externe).

Vous disposez de deux autres alternatives pour spécifier le compte à usurper l'identité.Premièrement, vous pouvez accéder à IIS et modifier le compte "anonyme" pour qu'il ait accès à la ressource au lieu de celui qu'IIS gère pour vous.La deuxième alternative consiste à cacher le compte et le mot de passe cryptés dans le registre.Cette étape est un peu compliquée et dépasse également le cadre de cette discussion.

Bonne chance!

Answer 2

Peut-être parce que IIS_WPG n'a pas accès à un dossier temporaire.Si vous pensez qu'il s'agit d'un problème d'autorisation, exécutez un Prochain sur le processus de travail asp.net et recherchez les erreurs AccessDenied.

Answer 3

J'ai rencontré cette erreur lors du diagnostic d'une application console qui écrivait dans des fichiers temporaires.Dans l'une de mes itérations de test, j'ai purgé tous les fichiers/répertoires temporaires pour une exécution « table rase ».J'ai résolu ce problème auto-infligé en me déconnectant puis en me reconnectant.

Answer 4

Vous pouvez utiliser Chemin.GetTempPath() pour savoir dans quel répertoire il essaie d'écrire.

Answer 5

J'avais le même problème avec une de mes applications ASP.Net.j'obtenais Chemin.GetTempPath() mais cela jetait une exception de :

"Impossible d'écrire dans le fichier "C:\Windows emp\somefilename", exception :L'accès au chemin "C:\Windows emp\somefilename" est refusé."

J'ai essayé quelques suggestions sur cette page, mais rien n'a aidé.

En fin de compte, je suis allé sur le serveur Web (serveur IIS) et j'ai modifié les autorisations sur le répertoire "C:\Windows emp" du serveur pour donner à l'utilisateur "Tout le monde" des autorisations complètes en lecture-écriture.

Et puis, finalement, l’exception a disparu et mes utilisateurs ont pu télécharger des fichiers depuis l’application.Phew!