Path.GetTempFileName – Der Verzeichnisname ist ungültig

https://stackoverflow.com/questions/55411

09-06-2019
|

Frage

Es tritt ein Problem auf, bei dem wir auf bestimmten Servern eine Fehlermeldung erhalten, dass der Verzeichnisname ungültig ist, wenn Path.GetTempFileName verwendet wird.Weitere Untersuchungen zeigen, dass versucht wird, eine Datei in c:\Dokumente und Einstellungen\Computername\aspnet\lokale Einstellungen emp zu schreiben (gefunden mit Path.GetTempPath).Da dieser Ordner vorhanden ist, gehe ich davon aus, dass es sich hierbei um ein Berechtigungsproblem in Bezug auf das asp.net-Konto handelt.

Einige haben mir gesagt, dass Path.GetTempFileName auf C:\Windows\Microsoft.NET\Framework\v2.0.50727 emporaryasp.net-Dateien verweisen sollte.

Mir wurde auch gesagt, dass dieses Problem möglicherweise an der Reihenfolge liegt, in der IIS und .NET auf dem Server installiert wurden.Ich habe das typische „aspnet_regiis -i“ ausgeführt und die Sicherheit der Ordner usw. überprüft.An diesem Punkt stecke ich fest.

Kann jemand etwas Licht ins Dunkel bringen?

**Update:**Es stellt sich heraus, dass die Bereitstellung des Zugriffs „IUSR_ComputerName“ auf den Ordner den Zweck erfüllt.Ist das das richtige Verfahren?Ich erinnere mich nicht daran, dies in der Vergangenheit getan zu haben, und möchte natürlich Best Practices befolgen, um die Sicherheit aufrechtzuerhalten.Dies ist schließlich Teil eines Datei-Upload-Prozesses.

Lösung

Dies ist wahrscheinlich eine Kombination von Identitätswechsel und eine Nichtübereinstimmung der verschiedenen Authentifizierungsverfahren auftritt.

Es gibt viele Stücke; Ich werde versuchen, über sie eins nach dem anderen zu gehen.

Identitätswechsel ist eine Technik zur „vorübergehend“ schalten das Benutzerkonto, unter denen ein Faden läuft. Im Wesentlichen erhält der Faden kurz die gleichen Rechte und Zugang - nicht mehr und nicht weniger - als das Konto, das imitierte wird. Sobald der Faden der Web-Seite getan schafft es „kehrt“ wieder auf das ursprüngliche Konto und wird für den nächsten Anruf bereit. Diese Technik wird verwendet, auf Ressourcen zuzugreifen, die nur der Benutzer in Ihre Website muss den Zugriff angemeldet. Halten Sie das Konzept für eine Minute.

Jetzt wird standardmäßig läuft ASP.NET eine Website unter einem lokalen Konto mit dem Namen ASPNET . Auch hier standardmäßig nur die ASPNET-Konto und die Mitglieder der Gruppe Administratoren in diesem Ordner schreiben können. Ihre temporären Ordner ist unter diesem Konto des Geltungsbereichs. Dies ist der zweite Teil des Puzzles.

Identitätswechsel geschieht nicht von allein. Es muss absichtlich in Ihrer web.config einschalten.

<identity impersonate="true" />

Wenn die Einstellung fehlt oder auf false gesetzt, Ihr Code rein ausführen und einfach unter dem ASPNET-Konto oben erwähnt. Angesichts Ihrer Fehlermeldung, ich bin sicher, dass Sie Identitätswechsel haben = true. Es ist nichts falsch mit dem! Identitätswechsel hat Vor- und Nachteile, die außerhalb dieser Diskussion gehen.

Es gibt noch eine Frage: wenn Sie Identitätswechsel verwenden, , die imitierte Konto wird

Wenn Sie das Konto in der web.config angeben ( vollständige Syntax der Identität Element hier ), verkörperte das Konto ist derjenige, der die IIS an ASP.NET übergeben. Und das hängt davon ab, wie der Benutzer (oder nicht) in die Website authentifiziert hat. Das ist Ihr drittes und letztes Stück.

Das Konto IUSR_Computername ist ein Low-Rechte von IIS-Konto erstellt. Standardmäßig ist dieses Konto das Konto, unter dem ein Web-Aufruf läuft , wenn der Benutzer nicht authentifiziert werden kann . Das heißt, der Benutzer kommt in als "anonymous".

Insgesamt ist es das, was mit Ihnen geschieht:

Ihre Benutzer versuchen, die Website zuzugreifen, und IIS konnte die Person aus irgendeinem Grunde nicht authentifizieren. Da anonyme Zugriff aktiviert ist, (oder würden Sie IUSRComputerName den temporären Ordner nicht sehen Zugriff), ermöglicht IIS den Benutzer in irgendeiner Weise, sondern als allgemeine Benutzer. ASP.NET-Code ausgeführt und nimmt die Identität dieses generischen IUSR___ComputerName „Gast“ Konto; Erst jetzt wird der Code keinen Zugriff auf die Dinge haben, dass das ASPNET-Konto Zugriff hatte, seinen eigenen temporären Ordner enthält.

Die Gewährung IUSR_ComputerName WRITE Zugriff auf den Ordner macht Ihre Symptome verschwinden.

Aber, dass nur die Symptome. Sie müssen überprüfen, warum die Person kommt als "Anonymous / Gast"?

Es gibt zwei mögliche Szenarien:

a) Sie soll IIS für die Authentifizierung verwenden, aber die Authentifizierungseinstellungen in IIS für einige Ihrer Server sind falsch.

In diesem Fall müssen Sie den anonymen Zugriff auf diesen Servern deaktivieren, so dass die üblichen Authentifizierungsmechanismen stattfinden. Beachten Sie, dass Sie vielleicht noch an die Benutzer gewähren, müssen Zugriff auf diesen temporären Ordner, oder verwenden Sie einen anderen Ordner stattdessen ein, zu der der Benutzer bereits Zugriff haben.

Ich habe mit diesem Szenario oft gearbeitet, und ehrlich gesagt gibt es Ihnen weniger Kopfschmerzen den Ordner Temp zu verzichten; erstellen Sie einen speziellen Ordner auf dem Server, stellen Sie die richtigen Berechtigungen, und legen Sie seine Position in web.config.

b) Sie wollten die Menschen nicht sowieso authentifizieren, oder man wollte ASP.NET Forms Authentifizierung verwenden (die den anonymen Zugriff IIS verwendet, um Bypass-Kontrollen in IIS und lässt ASP.NET die Authentifizierung direkt)

Griff

Dieser Fall ist etwas komplizierter.

You sollte IIS gehen und alle Formen der Authentifizierung andere als „Anonymous Access“ deaktivieren. Beachten Sie, dass Sie nicht, dass in der Entwickler-Box tun, weil der Debugger integrierte Authentifizierung aktiviert werden muss. So wird Ihre Debug-Box ein bisschen anders als der reale Server verhalten; nur sich bewusst sein, dass.

Dann müssen Sie entscheiden, ob Sie Identitätswechsel OFF oder umgekehrt schalten sollen, das Konto angeben, in der web.config zu verkörpern. Haben die erste, wenn Ihr Webserver nicht außerhalb Ressourcen benötigen (wie eine Datenbank). Haben die letztere Variante, wenn Ihre Website muss unter einem Konto ausführen, die Zugriff auf eine Datenbank (oder eine andere außerhalb Ressource) hat.

Sie haben zwei weitere Alternativen das Konto angeben, zu imitieren. Man könnte Sie IIS gehen und ändern Sie die „anonymous“ Konto sein mit Zugriff auf die Ressource statt der IIS für Sie verwaltet. Die zweite Alternative ist das Konto und Kennwort in der Registrierung verschlüsselt zu verstauen. Dieser Schritt ist ein wenig kompliziert und geht auch über den Rahmen dieser Diskussion.

Viel Glück!

Andere Tipps

Könnte sein, weil IIS_WPG hat keinen Zugriff auf einen temporären Ordner. Wenn Sie denken, es ist ein Berechtigungsproblem, führen Sie eine Procmon auf asp .net Arbeitsprozess und überprüfen AccessDenied Fehler.

begegnete ich diesen Fehler während einer Konsole app Diagnose, die in temporären Dateien schreibt. In einem meiner Testiterationen gespült ich alle Dateien / Verzeichnisse in Temp für eine ‚saubere Chiefer‘ run. Ich löste dieses Problem selbst verursacht, indem Sie sich aus und wieder ein.

Sie können Path.GetTempPath () , um herauszufinden, welches Verzeichnis auf, die es zu schreiben versucht.

Ich habe das gleiche Problem mit einem meiner ASP.Net-Anwendungen. Ich war immer Path.GetTempPath () , aber es wirft eine Ausnahme:

"kann nicht schreiben in Datei "C: \ Windows \ Temp \ somefilename", Ausnahme: Zugriff auf den Pfad "C:". Verweigert wird" \ Windows \ Temp \ somefilename

Ich habe versucht, ein paar Vorschläge zu dieser Seite, aber nichts half.

Am Ende ging ich auf den Webserver (IIS-Server) und geänderte Berechtigungen auf den Server des „C: \ Windows \ Temp“. Verzeichnis mit dem „Jedem“ Benutzer vollen Lese- und Schreibzugriff geben

Und dann, endlich, ging die Ausnahme weg, und meine Benutzer Dateien von der Anwendung herunterladen können. Puh!

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow