Ieri notte, insieme al mio amico Fabio, stavamo sviluppando un applicazione web non eccessivamente complessa fino a quando non si è verificato un problema di permessi.
Entro meglio nel dettaglio per far capire la cosa:
La prima caratteristica dell'applicazione è che dovendo accedere a determinate cartelle protette non doveva usare l'utente ASP.NET per eseguire le operazioni, ma bensi un utente membro di un dominio che per comodiftà chiamerò farmuser.
Per far si che l'utente utilizzato non sia asp.net basta andare ad aggiungere nel web.config la riga sull'identity, come la seguente:
<identity impersonate="true" userName="farmuser" password="farmpass" />Fatto ciò sembra tutto ok, fino a quando non andavamo a utilizzare dei thread in una situazione simile alla seguente:
La pagina aspx lancia un nuovo thread (nel mio caso passando per un metodo statico) ed seguiva un blocco di codice tipo il seguente:
indexerThread = new Thread(new ThreadStart(Run));
indexerThread.Priority = ThreadPriority.Lowest;
indexerThread.Name = "Indexer";
indexerThread.Start();Il metodo statico run eseguiva delle operazioni su file, e qui sono cominciati gli errori. :)
L'inghippo lo abbiamo trovato nei nuovi file creati dal metodo run che avevano come utente ASP.NET, ma poi quando dovevano essere rinominati e/o cancellati dall'utente farmuser, il runtime ci stampava un bell'errore di accesso negato.
Armati di pazienza (molta più Fabio che io) tramite
WindowsIdentity.GetCurrent().NamePer risolvere il problema (dopo vari tentativi e ricerche su google) siamo arrivati a questa soluzione:
internal static System.Security.Principal.WindowsIdentity ApplicationIdentity;dentro il nostro metodo statico
ApplicationIdentity = System.Security.Principal.WindowsIdentity.GetCurrent();i
ndexerThread = new Thread(new ThreadStart(Run));
indexerThread.Priority = ThreadPriority.Lowest;
indexerThread.Name = "Indexer";
indexerThread.Start();
e dentro il run
ApplicationIdentity.Impersonate();
Figuriamoci cosa bisogna fare quando si lancia un processo esterno con System.Process.Start().....
...forse settare su machine.config,process model un utente con più diritti del debole utente ASPNET... Con la tendenza di Microsoft a spronarci a lavorare in Multi-Threading anche nelle applicazioni web, il tuo post solleva un comportamento dell'impersonificazione tanto inaspettato quanto , effettivamente , documentato http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html/vxconImpersonation.asp
E' palese che il Framework 2.0 si sia "aperto" ancora di più al Multi-Threading esponendoci strumenti già pronti a fronte di farci scrivere le nostre piccole , ma non banali , classi "pseudo-asincrone" , tuttavia sia il tuo post che la guida mi hanno fatto cadere dalle nuvole:
"Note : Impersonation is local to a particular thread. When code changes threads, such as when using thread pooling, the new thread executes using the process identity by default."
non comprendo molto questo comportamento , ma mi aiutato ancora di più a rafforzare l'idea che l'impersonificazione non è una pratica "positiva" , che se una applicazione web deve leggere su un file locale è meglio pensare ad una applicazione "standard" e che se il cliente insiste estendere il costo e la liberatoria sui danni derivati dal programma
cmq pensare di poter fare Multi-Threading su http è una figata , alla faccia di asp,php e affini
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Stampa 
Download 
10annidi.ASPItalia.com: iscriviti alla competizione e vinci fantastici premi ogni mese!
ciao, prendo al balzo il tuo post, per chiederti, come faccio ad utilizzaere l'mpersonate su server diversi in dominio dove le utenze e le pwd cambiano da server a server.
posso parametrizzare il web config in modo che nel tag identity passo delle variabili invece delle costanti(user e pwd)?
ciao
grazie
angelo
Continua »»» | Rispondi »»»