Sicurezza e attendibilità
.NET Framework prevede modello di sicurezza che tratta le applicazioni in modo diverso a seconda della relativa origine. Gli eseguibili e gli assembly provenienti dal computer di un utente vengono in genere eseguiti con attendibilità totale; gli stessi file eseguibili e assembly eseguiti su Internet vengono in genere eseguiti con attendibilità parziale. Ciò consente di impedire a codice dannoso di leggere o modificare le informazioni a cui non deve accedere, ad esempio file locali, elementi negli Appunti e altre risorse. Se un eseguibile chiama un assembly, che a sua volta chiama un altro assembly che richiede un determinato livello di attendibilità, viene applicato il livello di attendibilità più basso di tutti i componenti della catena. Tuttavia, un amministratore di un computer può impostare autorizzazioni specifiche che eseguono l'override delle autorizzazioni predefinite.
Una panoramica del modello di sicurezza è disponibile in Secure, Light-Weight Client-Side Controls ed è possibile ottenere informazioni più approfondite sul modello di sicurezza in Sicurezza dall'accesso al codice in Pratica. Una buona panoramica sulla sicurezza delle librerie (particolarmente importante per gli oggetti UserControl in una pagina Web) è disponibile in Uso di librerie da codice parzialmente attendibile e altre informazioni di sicurezza sui controlli gestiti sono disponibili in Scrittura di controlli gestiti protetti.
Autorizzazioni
La maggior parte degli oggetti gestiti e dei membri nell'API Tablet PC Technologies ha due requisiti:
- L'esecuzione è sempre necessaria.
- FullTrust è necessario quando viene eseguita l'azione di sicurezza InheritanceDemand . Ciò significa che l'attendibilità totale è necessaria quando una classe derivata eredita una classe o esegue l'override di un metodo da Tablet PC SDK.
Nella tabella seguente sono elencate le classi e i membri che richiedono autorizzazioni aggiuntive. Le autorizzazioni per una determinata classe si applicano anche a tutti i relativi membri non elencati in questa tabella.
Nota
In genere è preferibile usare un controllo anziché un handle (IntPtr) per i costruttori, perché i controlli richiedono meno autorizzazioni. Analogamente, è preferibile usare un oggetto Graphics anziché un handle per Renderer.Draw, Renderer.InkSpaceToPixel e Renderer.PixelToInkSpace.
Nota
Le proprietà InkCollector.Handle e InkOverlay.Handle non richiedono l'autorizzazione SecurityPermissionFlag.UnmanagedCode se l'handle è per un controllo Windows Forms, ma per altre finestre.
Nota
Per la classe PenInputPanel, i metodi e le proprietà seguenti richiedono SecurityPermissionFlag.AllFlags: PenInputPanel(IntPtr), AttachedEditWindow, Busy, CommitPendingInput, CurrentPanel, DefaultPanel, EnableTsf, Factoid, Height, HorizontalOffset, InputFailed, Left, MoveTo, PanelChanged, PanelMoving, Refresh , Top, VerticalOffset, Visible, VisibleChanged e Width.
Altre considerazioni
Ecco alcune altre considerazioni note sulla sicurezza:
- Microsoft Internet Explorer 6 o versione successiva è necessario affinché i controlli Web funzionino correttamente. Con Internet Explorer 5.5, vengono caricati solo i controlli gestiti iniziali; non è possibile caricare controlli aggiuntivi in modo dinamico in fase di esecuzione.
- Se si usa Windows XP Service Pack 2 (SP2) e CLR1.0, i controlli Web in Internet Explorer richiedono l'aggiunta del sito come sito attendibile, anche se si trovano nell'area Intranet. Tuttavia, quando si esegue questa operazione, non verranno più eseguiti nell'area Sito attendibile, anche se vengono eseguiti nell'area Intranet. Questo problema è stato risolto con CLR1.1.