Pretese di protezione
Aggiornamento: novembre 2007
Per assicurarsi che solo i chiamanti dotati di una specifica autorizzazione possano chiamare il codice, è possibile esigere in maniera dichiarativa o imperativa che tali chiamanti dispongano di un'autorizzazione o di un set di autorizzazioni specifiche. A seguito di tale pretesa viene eseguito un controllo di protezione per applicare restrizioni sul codice chiamante. Durante un controllo di protezione, viene analizzato lo stack di chiamate e vengono esaminate le autorizzazioni di ogni chiamante incluso nello stack, per determinare se al chiamante sia stata concessa l'autorizzazione pretesa. Se viene rilevata la presenza di un chiamante che non dispone dell'autorizzazione richiesta, il controllo di sicurezza avrà esito negativo e verrà generato un oggetto SecurityException. Le sole pretese che non generano un'analisi dello stack sono le pretese di collegamento, per le quali viene controllato solo il chiamante immediato.
È possibile fare in modo che venga eseguito un controllo di protezione ogni volta che viene chiamato un particolare metodo o prima che venga eseguito un particolare blocco di codice. Se si desidera che venga eseguito un controllo di protezione quando viene chiamato un membro di una particolare classe, è possibile specificare una pretesa prima della classe, in modo che venga applicata a ogni membro. Di seguito in questo argomento viene mostrato come e quando generare pretese di protezione, oltre ai motivi che giustificano la scelta di un tipo particolare.
Se si sta scrivendo una libreria che accede direttamente a una risorsa protetta e tale accesso è esposto al chiamante, è necessario inviare una pretesa di protezione nella libreria per verificare che tutti i chiamanti compresi nello stack di chiamate dispongano dell'autorizzazione per accedere alla risorsa. Le pretese possono essere dichiarative o imperative. È necessario che le pretese non vengano mai generate in un costruttore di classe, perché non vi è alcuna garanzia che il codice del costruttore venga eseguito in un determinato punto o in un particolare contesto. Dal momento che lo stato dello stack di chiamate in un costruttore di classe non è ben definito, le pretese generate su questo possono produrre risultati inattesi e indesiderati.
Indipendentemente dal tipo di pretesa che si desidera effettuare, è consigliabile attenersi alle seguenti istruzioni:
Assicurarsi che il chiamante abbia origine in un sito o un'area particolare o che sia stato firmato da un editore particolare imponendo che i chiamanti dispongano di una specifica autorizzazione di identità. È tuttavia necessario seguire questa istruzione solo quando si riconosce, e non quando si rifiuta, ulteriore accesso in base a una corrispondenza di identità. Poiché è piuttosto semplice modificare o mascherare l'identità del codice, il rifiuto dell'accesso in base alla sola identità non costituisce un modo affidabile di proteggere dall'accesso non autorizzato il codice e le risorse cui il codice accede.
Assicurarsi che un oggetto possa essere creato solo da chiamanti dotati di un'autorizzazione specifica inserendo la pretesa al livello di classe dell'oggetto. Si supponga ad esempio che sia disponibile una classe denominata myFileStream, derivata dalla classe FileStream, e che si desideri limitare ai chiamanti autorizzati la possibilità di creare istanze di myFileStream. Si dovrà specificare una richiesta dichiarativa di un oggetto FileIOPermission, che rappresenta il diritto di accedere al flusso creato da myFileStream a livello della classe myFileStream.
È anche possibile inserire nel codice pretese che consentono di impostare o ottenere una proprietà. È in generale necessario che le pretese di autorizzazioni meno restrittive vengano inserite nella funzione di accesso get invece che nella funzione di accesso set, a meno che la proprietà non contenga informazioni sensibili, quali una password.
.gif "Nota")
Nota:La semantica dei controlli di protezione basati sui ruoli è leggermente diversa da quella dei controlli di protezione dall'accesso di codice. Per ulteriori informazioni, vedere Protezione basata sui ruoli.
Nota:Le pretese possono essere applicate solo a livello di classe, metodo, evento e proprietà. Assembly e singoli membri variabili non privati non sono protetti dalle pretese. Le pretese impostate a livello di assembly o di variabile non privata non producono avvisi del compilatore. È quindi importante utilizzare proprietà invece di membri pubblici per garantire la protezione fornita dalla pretesa.
Vedere anche
Concetti
Scrittura di librerie di classi protette