Chemin d'accès.GetTempFileName — nom de Répertoire n'est pas valide
En cours d'exécution dans un problème où, sur certains serveurs, on obtient une erreur que le nom de répertoire n'est pas valide lors de l'utilisation de Chemin.GetTempFileName. Complément d'enquête montre qu'il est en train d'essayer d'écrire un fichier c:\Documents et le Paramètre\computername\aspnet\local settings\temp (trouvé par l'aide de Chemin.GetTempPath). Ce dossier existe, donc je suis en supposant que cela doit être un problème d'autorisations à l'égard de la asp.net compte.
J'ai été dit par certains que le Chemin d'accès.GetTempFileName doit être dirigée vers C:\Windows\Microsoft.NET\Framework\v2.0.50727\temporaryasp.net les fichiers.
J'ai également été dit que ce problème peut être dû à l'ordre dans lequel IIS et .NET lorsqu'il est installé sur le serveur. J'ai fait la typique "aspnet_regiis -i' et vérifié la sécurité sur les dossiers etc. À ce point, je suis coincé.
Quelqu'un peut jeter un peu de lumière sur cette?
**Mise à jour:**s'avère que l'offre de "iusr_ computername" accès au dossier de l'affaire. Est-ce la bonne procédure? Je ne me rappel le faire dans le passé, et, évidemment, vous voulez suivre les meilleures pratiques pour maintenir la sécurité. C'est, après tout, une partie d'un fichier, le processus de chargement.
OriginalL'auteur Douglas Anderson | 2008-09-10
Vous devez vous connecter pour publier un commentaire.
C'est probablement une combinaison de l'emprunt d'identité et un décalage de différentes méthodes d'authentification se produise.
Il y a de nombreux morceaux; je vais essayer de les passer en revue un par un.
Usurpation d'identité est une technique de "temporairement" basculer le compte d'utilisateur sous lequel un thread est en cours d'exécution. Essentiellement, le fil brièvement les gains les mêmes droits et accès -- ni plus, ni moins, que le compte est représenté. Dès que le fil est fait de la création de la page web, il "revient" sur le dos pour le compte d'origine et se prépare pour le prochain appel. Cette technique est utilisée pour accéder à des ressources que seul l'utilisateur connecté à votre site web de a accès. Tenir sur le concept pendant une minute.
Maintenant, par défaut ASP.NET gère un site web sous un compte local appelé ASPNET. Encore une fois, par défaut, seul le compte ASPNET et les membres du groupe Administrateurs peuvent écrire sur ce dossier. Votre dossier temporaire est en vertu de ce compte de sa juridiction. C'est la deuxième pièce du puzzle.
Usurpation d'identité n'arrive pas sur son propre. Elle doit être à son tour sur intentionnellement dans votre site web.config.
Si le paramètre est manquant ou false, votre code s'exécute pur et simple sous le compte ASPNET mentionnés ci-dessus. Compte tenu de votre message d'erreur, je suis positif que vous avez de l'emprunt d'identité=true. Il n'y a rien de mal à cela! L'usurpation d'identité a des avantages et des inconvénients qui vont au-delà de cette discussion.
Il y a une question: lorsque vous utiliser l'emprunt d'identité, qui compte est représenté?
Sauf si vous spécifiez le compte dans le web.config (syntaxe complète de l'identité de l'élément ici), le compte empruntée est celle que l'IIS remis à ASP.NET. Et tout dépend de ce que l'utilisateur est authentifié (ou pas) dans le site. C'est votre troisième et dernière pièce.
Le compte iusr_ computername est faible compte créé par IIS. Par défaut, ce compte est le compte sous lequel un appel web s'exécute si l'utilisateur n'a pas pu être authentifié. Qui est, l'utilisateur entre dans un "anonyme".
En résumé, c'est ce qui se passe pour vous:
Votre utilisateur essaie d'accéder au site web, et IIS ne peut pas authentifier la personne pour une raison quelconque. Parce que l'accès Anonyme est activé, (ou vous ne verriez pas IUSRComputerName accès au dossier temp), IIS permet à l'utilisateur de toute façon, mais comme un utilisateur générique. Votre ASP.NET le code s'exécute et emprunte l'identité de ce générique IUSR___ComputerName compte "invité"; seulement maintenant que le code n'a pas accès à ce que le compte ASPNET eu accès, y compris son propre dossier temporaire.
Octroi Iusr_nom_ordinateur accès en ÉCRITURE au dossier rend vos symptômes disparaissent.
Mais que seulement les symptômes. Vous avez besoin de revoir pourquoi la personne à venir comme "Anonyme/Invité"?
Il y a deux scénarios possibles:
a) Vous avez l'intention d'utiliser les services internet pour l'authentification, mais les paramètres d'authentification IIS pour certains de vos serveurs sont mauvais.
Dans ce cas, vous devez désactiver l'accès Anonyme sur ces serveurs, de sorte que l'habitude des mécanismes d'authentification lieu. Notez que vous pourriez encore besoin d'accorder à vos utilisateurs l'accès à ce dossier temporaire, ou utiliser un autre dossier, celui auquel vos utilisateurs ont déjà accès.
J'ai travaillé avec ce scénario plusieurs fois, et franchement, il vous donne moins de maux de tête de renoncer le dossier Temp; créer un dossier dédié sur le serveur, définissez les autorisations appropriées, et de définir son emplacement dans le web.config.
b) Vous ne voulez pas à s'authentifier les gens de toute façon, ou que vous vouliez utiliser ASP.NET l'Authentification par Formulaires (qui utilise IIS de l'accès Anonyme pour contourner les contrôles dans les services internet et permet de ASP.NET gérer l'authentification directement)
Ce cas est un peu plus compliqué.
Vous devriez aller pour IIS et désactiver toutes les formes d'authentification autre que "l'Accès Anonyme". Notez que vous ne pouvez pas le faire dans le développement de la case, parce que le débogueur a besoin de l'Authentification Intégrée à être activé. Si votre débogage zone va se comporter un peu différent que le serveur réel; juste être conscient de cela.
Ensuite, vous devez décider si vous devez tourner à l'emprunt d'identité OFF, ou, à l'inverse, pour indiquer le compte à usurper l'identité sur le web.config. Faire la première si votre serveur web n'a pas besoin des ressources de l'extérieur (comme une base de données). Faire la dernière, si votre site web a besoin pour s'exécuter sous un compte qui dispose d'un accès à une base de données (ou d'autres ressources de l'extérieur).
Vous avez deux alternatives pour spécifier le compte d'imiter. L'un, vous pouvez aller à IIS et modifier le compte "anonyme" d'être l'un avec l'accès à la ressource, au lieu d'un IIS gère pour vous l'. La seconde alternative est de ranger le compte et le mot de passe crypté dans la base de registre. Cette étape est un peu plus complexe et va au-delà de la portée de cette discussion.
Bonne chance!
OriginalL'auteur Euro Micelli
Pourrait être parce que IIS_WPG n'ont pas accès à un dossier temp. Si vous pensez que c'est un problème d'autorisation, exécuter un Procmon sur asp.net processus de travail et vérifier AccessDenied erreurs.
OriginalL'auteur Gulzar Nazim
Vous pouvez utiliser Chemin.GetTempPath() pour savoir dans quel répertoire auquel il essaie d'écrire.
OriginalL'auteur Mark Cidade
J'ai eu le même problème avec un de mes ASP.Net des applications. J'ai été faire Chemin.GetTempPath() mais il a été lancer une exception de:
"Impossible d'écrire dans le fichier "C:\Windows\Temp\somefilename", exception: l'Accès au chemin "C:\Windows\Temp\somefilename" 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 IIS (serveur) et changé les autorisations sur le serveur "C:\Windows\Temp" répertoire de donner le "tout le monde" complet de l'utilisateur en lecture-écriture.
Et puis, enfin, l'exception s'en alla, et mes utilisateurs peuvent télécharger des fichiers à partir de l'application. Ouf!
OriginalL'auteur Mike Gledhill
J'ai rencontré cette erreur alors que le diagnostic d'une application console qui a été écrit dans les fichiers temporaires. Dans un de mes itérations de test j'ai purgé tous les fichiers/répertoires temp pour un "rase" exécuter. J'ai résolu cette auto-infligé question par de vous déconnecter et de vous reconnecter.
OriginalL'auteur Brian