Condividi tramite


Richieste di sicurezza

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 sicurezza per applicare restrizioni sul codice chiamante. Durante un controllo di sicurezza, 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 sicurezza 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 sicurezza 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 sicurezza, 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 sicurezza 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 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.

    NotaNota

    La semantica dei controlli di sicurezza basati sui ruoli è leggermente diversa da quella dei controlli di sicurezza per l'accesso al codice.Per ulteriori informazioni, vedere Sicurezza basata sui ruoli.

    NotaNota

    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

Riferimenti

SecurityException

Concetti

Sicurezza dall'accesso di codice

Scrittura di librerie di classi protette

Cronologia delle modifiche

Data

Cronologia

Motivo

Luglio 2010

Sono state rimosse informazioni obsolete.

Correzione di bug nel contenuto.