Di seguito gli articoli e le fotografie pubblicati nella giornata richiesta.
Articoli del 23/01/2013
Siccome non son riuscito, per l'articolo precedente sul mio blog, a fare una cattura dello schermo di Windows, mentre se ne stava davanti a tutto la schermata dell'UAC per procedere all'elevazione dei previlegi - evidentemente non è intercettata la pressione del tasto Print (Stamp) e la combinazione Ctrl-Print - ho fatto la cosa più semplice di questo mondo, cioè usare il copia-incolla via fotocamera dell'iPhone...
Ed ho scoperto un bel po' di pixel! Zooma talmente tanto da vedere i singoli pixel del display del mio notebook, che ha una densità di 114 dpi. Niente male vedere i pixel ad uno ad uno!
La foto che vedete sotto è stata semplicemente croppata, ma non stata riscalata.
Sto girovagando da un bel po' attorno al problema di gestire l'elevazione dei previlegi con Windows. Il pattern della situazione è alquanto tipico e che capita a tanti sviluppatori, ossia lanciare un eseguibile esterno con diritti di amministratore, semplicemente perché l'eseguibile esterno deve intraprendere operazioni di manutenzione sulle installazione, come ad esempio un software di aggiornamento.
Anzitutto è necessario prevedere che l'eseguibile sia contrassegnato in modo tale che esso pretenda diritti di amministrazione prima di partire. Per fare questo basta scrivere qualcosina del manifest file esterno o iniettarlo nel manifest interno come risorsa:
<?xml version="1.0" encoding="UTF-8"
standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<assemblyIdentity version="2.3.0.0"
processorArchitecture="X86" name="YourUpdater.exe"
type="win32"/>
<description>Update Tool</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
</application>
</compatibility>
</assembly>
Come potete vedere, i previlegi pretendono di essere amministratore, requireAdministrator, poi sarà carico del sistema operativo tramite UAC (User Access Control) o tramite PCA (Program Compatibility Assistant) a gestire o meno la richiesta all'utente tramite opportuno dialogo con cui intraprendere l'elevazione.
Purtroppo Microsoft continua a rimettere in discussione le politiche di gestione ed ogni qualche mese, il comportamento cambia a seguito di nuove invenzioni di Redmond. Anche alcuni stessi sviluppatori all'interno di Microsoft hanno manifestato tutto il loro disappunto per continuare a cambiare la carte in tavola, cosa su cui gli sviluppatori impazziscono e gli utenti finali ancor di più.
Sostanzialmente se all'interno dell'eseguibile è presente un manifest che dice cosa fare, il problema non si pone, o meglio, non dovrebbe porsi. Esso dice cosa deve fare il sistema, senza che si inventi nulla in particolare. In realtà, già a partire da Windows Vista, il sistema provava per conto suo a tentare l'elevazione semplicemente perché il nome ed il codice binario conteneva qualche occorrenza delle parole "setup", "installer" e "update". Tutto questo però portava al succedere sia dei "false positive" che dei "false negative", con gravi incazzature degli sviluppatori.
Per rendervi conto dell'evoluzione dei fatti, vi lascio a questi articoli:
Ora vi introduco al codice nel mio processo che gira in modalità standard:
Try
updProcess = New Process()
With updProcess.StartInfo
.UseShellExecute = False
.FileName = updPath
.WorkingDirectory = CurDir()
.Arguments = arguments
End With
updProcess.Start()
fileExistsAndLaunched = True
Catch ex As Exception
MsgBox(ex.ToString)
End Try
In realtà ho scoperto una cosa molto più semplice e cioè che Process.Start, se impostato con StartInfo.UseShellExecute a falso, non è in grado di far scattare tutto questo sistema di elevazione dei previlegi, ma esso si ferma a sollevare un'eccezione che recita più o meno così:
ex {Name = "Win32Exception" FullName = "System.ComponentModel.Win32Exception"} System.Type
"Per eseguire l'operazione richiesta è necessaria l'esecuzione con privilegi elevati"
La soluzione è semplice: ricordarsi di farlo con UseShellExecute impostato a vero, anche se all'atto dell'istanziazione di oggetto di classe System.Diagnostics.Process, tale proprietà è già impostata a true, quindi il problema non si pone, a meno che non abbiate tra le mani, come è capitato a me, il caso in cui UseShellExecute era stato forzato a falso...
In Windows 7 è relativamente semplice far partire un eseguibile come un altro utente, anche se non lo sa praticamente nessuno. Basta premere il tasto Shift prima di far comparire il menu contestuale sull'eseguibile o un suo collegamento. Il menu contestuale sarà "addizionato" di una ulteriore voce di menu, "Esegui come altro utente", che ovviamente potete scegliere.
L'opzione è decisamente utile in parecchie circostanze, anche se principalmente serve agli sviluppatori che vogliono provare uno scenario reale, cioè quello di un utente standard, diverso dal profilo che usano solitamente per sviluppare, che invece è di tipo amministrativo e che sostanzialmente può effettuare tutte le operazioni del caso. Diversamente l'utenza finale di prodotti, codici, script ed eseguibili molto spesso non ha i previlegi di amministratore sul proprio computer e quindi i comportamenti di tante applicazioni si scoprono solo nel momento in cui vengono rilasciati, se non è stata considerata tale eventualità, come da prassi anche ormai del più ignaro esperto IT.
In Windows 8 la stessa cosa è possibile anche nell'ambiente desktop, Windows 8 desktop, mentre non lo è affatto in Windows 8 start: se si preme il tasto Shift nel momento in cui cliccate il tasto destro sopra un elemento, nella barra inferiore non comparirà la possibilità di eseguire come altro utente l'elemento selezionato.
In realtà tale voce è possibile farla comparire, andando nell'Editor Criteri di gruppo locali, che è disponibile su Windows 8 Professional o superiore. Per farlo partire, basta andare dentro Start, magari cliccando il tasto Windows e mettersi a scrivere "gpedit.msc": l'ambiente Start effettuerà subito la ricerca di testo che avete inserito e la troverà praticamente subito, alché basterà cliccare il tasto Invio per far partire l'eseguibile.
A questo punto si apre l'editor e scegliete la voce Criteri Computer locale > Configurazione utente > Modelli amministrativi > Menu Start e barra delle applicazioni.
Qui dentro trovate la voce Mostra il comando "Esegui come altro utente" nel menu Start, fate doppio clic per accedere al dialogo di configurazione dell'opzione, il quale vi introdurrà all'opzione attraverso il testo indicato nella guida:
Questa impostazione dei criteri mostra o nasconde il comando "Esegui come altro utente" nella barra dell'applicazione Start.
Se si abilita questa impostazione, gli utenti potranno accedere al comando "Esegui come altro utente" dal menu Start per le applicazioni che supportano questa funzionalità.
Se si disabilita o non si configura questa impostazione, gli utenti non potranno accedere al comando "Esegui come altro utente" dal menu Start per nessuna applicazione.
Nota: questa impostazione non impedisce agli utenti di utilizzare altri metodi, ad esempio MAIUSC + menu di scelta rapida delle Jump List dell'applicazione nella barra delle applicazioni per visualizzare il comando "Esegui come altro utente"
Attivate l'opzione selezionando a sinistra "Attivata" ed uscitevene. Viene creata una chiave di registro che è collocata nel seguente punto:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects\{2EFD5E24-75E6-4F3C-B2B6-E231206FAE9A}User\Software\Policies\Microsoft\Windows\Explorer
La chiave ha come nome ShowRunAsDifferentUserInStart e viene impostata ad 1 per abilitare la voce nel menu Start ed invece a 0 se la si vuole togliere.
Fotografie del 23/01/2013
Nessuna fotografia trovata.
|