Path.GetTempFileName: il nome della directory non è valido

Question

Si è verificato un problema a causa del quale su alcuni server viene visualizzato un errore indicante che il nome della directory non è valido quando si utilizza Path.GetTempFileName.Ulteriori indagini mostrano che sta tentando di scrivere un file in c:\Documents and Setting\computername\aspnet\local settings emp (trovato utilizzando Path.GetTempPath).Questa cartella esiste quindi presumo che si tratti di un problema di autorizzazioni rispetto all'account asp.net.

Alcuni mi hanno detto che Path.GetTempFileName dovrebbe puntare ai file C:\Windows\Microsoft.NET\Framework\v2.0.50727 emporanyasp.net.

Mi è stato anche detto che questo problema potrebbe essere dovuto all'ordine in cui IIS e .NET sono stati installati sul server.Ho eseguito il tipico "aspnet_regiis -i" e controllato la sicurezza sulle cartelle, ecc.A questo punto sono bloccato.

Qualcuno può far luce su questo?

**Aggiornamento:**Risulta che fornire l'accesso "IUSR_ComputerName" alla cartella risolve il problema.È la procedura corretta?Non mi sembra di ricordare di averlo fatto in passato e, ovviamente, voglio seguire le migliori pratiche per mantenere la sicurezza.Dopotutto, questo fa parte del processo di caricamento dei file.

Answer 1

Si tratta probabilmente di una combinazione di rappresentazione e di una mancata corrispondenza dei diversi metodi di autenticazione.

Ci sono molti pezzi;Cercherò di esaminarli uno per uno.

Rappresentazione è una tecnica per cambiare "temporaneamente" l'account utente con cui è in esecuzione un thread.In sostanza, il thread ottiene brevemente gli stessi diritti e accesso (né più né meno) dell'account che viene impersonato.Non appena il thread ha finito di creare la pagina web, "ripristina" l'account originale e si prepara per la chiamata successiva.Questa tecnica viene utilizzata per accedere a risorse a cui ha accesso solo l'utente che ha effettuato l'accesso al tuo sito web.Aggrappati al concetto per un minuto.

Ora, per impostazione predefinita, ASP.NET esegue un sito Web con un account locale chiamato ASPNET.Anche in questo caso, per impostazione predefinita, solo l'account ASPNET e i membri del gruppo Administrators possono scrivere in quella cartella.La tua cartella temporanea è sotto la competenza di quell'account.Questo è il secondo pezzo del puzzle.

La rappresentazione non avviene da sola.Deve essere attivato intenzionalmente nel tuo web.config.

<identity impersonate="true" />

Se l'impostazione è mancante o impostata su false, il codice verrà eseguito puro e semplice con l'account ASPNET menzionato sopra.Dato il tuo messaggio di errore, sono sicuro che tu abbia impersonation=true.Non c'è niente di sbagliato in questo!La rappresentazione presenta vantaggi e svantaggi che vanno oltre questa discussione.

Resta una domanda:quando usi la rappresentazione, quale account viene rappresentato?

A meno che non si specifichi l'account nel file web.config (sintassi completa dell'elemento identità qui), l'account rappresentato è quello che IIS ha consegnato ad ASP.NET.E questo dipende da come l'utente si è autenticato (o meno) nel sito.Questo è il tuo terzo e ultimo pezzo.

L'account IUSR_NomeComputer è un account con diritti limitati creato da IIS.Per impostazione predefinita, questo account è l'account con cui viene eseguita una chiamata Web se l'utente non può essere autenticato.Cioè, l'utente entra come "anonimo".

In sintesi, questo è quello che ti sta succedendo:

L'utente sta tentando di accedere al sito Web e per qualche motivo IIS non è riuscito ad autenticare la persona.Poiché l'accesso anonimo è attivo (o non vedresti IUSRComputerName accedere alla cartella temporanea), IIS consente comunque all'utente, ma come utente generico.Il codice ASP.NET viene eseguito e rappresenta questo account "ospite" IUSR___ComputerName generico;solo ora il codice non ha accesso alle cose a cui aveva accesso l'account ASPNET, inclusa la propria cartella temporanea.

Concedere a IUSR_ComputerName l'accesso in SCRITTURA alla cartella fa scomparire i sintomi.

Ma questi sono solo i sintomi.Devi rivedere perché la persona viene come "Anonimo/Ospite"?

Ci sono due scenari probabili:

a) Volevi utilizzare IIS per l'autenticazione, ma le impostazioni di autenticazione in IIS per alcuni dei tuoi server sono errate.

In tal caso, è necessario disabilitare l'accesso anonimo su tali server in modo che abbiano luogo i consueti meccanismi di autenticazione.Tieni presente che potresti comunque dover concedere ai tuoi utenti l'accesso a quella cartella temporanea o utilizzare invece un'altra cartella, a cui i tuoi utenti hanno già accesso.

Ho lavorato con questo scenario molte volte e, francamente, ti dà meno grattacapi rinunciare alla cartella Temp;crea una cartella dedicata nel server, imposta le autorizzazioni appropriate e imposta la sua posizione in web.config.

b) Non volevi comunque autenticare le persone o volevi utilizzare l'autenticazione basata su moduli ASP.NET (che utilizza l'accesso anonimo di IIS per ignorare i controlli in IIS e consente ad ASP.NET di gestire direttamente l'autenticazione)

Questo caso è un po’ più complicato.

Dovresti andare su IIS e disabilitare tutte le forme di autenticazione diverse da "Accesso anonimo".Tieni presente che non puoi farlo nella casella dello sviluppatore, perché il debugger necessita che l'autenticazione integrata sia abilitata.Quindi la tua casella di debug si comporterà in modo leggermente diverso dal server reale;basta esserne consapevoli.

Quindi, devi decidere se disattivare la rappresentazione o, al contrario, specificare l'account da impersonare nel web.config.Fai il primo se il tuo server web non ha bisogno di risorse esterne (come un database).Fai quest'ultimo se il tuo sito web deve essere eseguito con un account che ha accesso a un database (o qualche altra risorsa esterna).

Hai altre due alternative per specificare l'account da impersonare.Uno, potresti andare su IIS e cambiare l'account "anonimo" in uno con accesso alla risorsa invece di quello che IIS gestisce per te.La seconda alternativa è nascondere l'account e la password crittografati nel registro.Questo passaggio è un po’ complicato e va oltre lo scopo di questa discussione.

Buona fortuna!

Answer 2

Potrebbe essere perché IIS_WPG non ha accesso a una cartella temporanea.Se ritieni che sia un problema di autorizzazione, esegui a Procmone sul processo di lavoro asp.net e verificare la presenza di errori AccessDenied.

Answer 3

Ho riscontrato questo errore durante la diagnosi di un'app console che scriveva nei file temporanei.In una delle mie iterazioni di test ho eliminato tutti i file/directory temporanei per un'esecuzione "pulita".Ho risolto questo problema autoinflitto disconnettendomi e riconnettendomi.

Answer 4

Puoi usare Path.GetTempPath() per scoprire in quale directory sta tentando di scrivere.

Answer 5

Stavo riscontrando lo stesso problema con una delle mie applicazioni ASP.Net.stavo ottenendo Path.GetTempPath() ma stava lanciando un'eccezione di:

"Impossibile scrivere nel file "C:\Windows emp omefile", eccezione:L'accesso al percorso "C:\Windows emp omefile" è negato."

Ho provato alcuni suggerimenti in questa pagina, ma nulla ha aiutato.

Alla fine, sono andato sul server web (server IIS) e ho modificato le autorizzazioni sulla directory "C:\Windows emp" del server per fornire all'utente "Tutti" autorizzazioni di lettura-scrittura complete.

Poi, finalmente, l'eccezione è scomparsa e i miei utenti hanno potuto scaricare file dall'applicazione.Uff!