Eccezioni .NET che posso eseguire per Non autorizzato o Non autenticato

Ho parti di codice in cui voglio generare un'eccezione ogni volta che un utente non è autenticato/non autorizzato.Eccezioni .NET che posso eseguire per Non autorizzato o Non autenticato

Quindi, invece di scrivere la mia NotAuthenticatedException e NotAuthorizedException, mi chiedevo se non ci sono già alcuni standard C# per questi.

Posso immaginare un sacco di programmi lanciare Eccezioni simili, e non sarebbe molto utile se tutti "scrivono la propria ruota" di nuovo.

fonte

2013-03-19 Dirk Boer

È possibile utilizzare 'SecurityException' per entrambi gli scenari. – jags

Qual è il problema con la nuova NotAuthorizedException? Se pensi che non sia abbastanza incapsulato, incapsulalo in una classe statica. – Fendy

@Fendy Abbastanza sicuro che intende scrivere la sua * propria * NotAuthorizedException, non il codice effettivo 'lanciare una nuova NotAuthorizedException();' ... – anaximander

Utilizzare la classe C# AuthenticationException o InvalidCredentialException.

http://msdn.microsoft.com/en-us/library/system.security.authentication.authenticationexception.aspx

fonte

2013-03-19 09:49:36

Non penso che queste eccezioni siano appropriate per l'autorizzazione non riuscita o per un utente non autenticato (anonimo). Sono pensati per la situazione in cui un cliente presenta credenziali non valide, il che è diverso dal non presentare alcuna credenziale. – Joe

Penso che AuthenticationException sia perfettamente valido. Direttamente da MSDN: le classi lanciano questa eccezione quando il client o il server non possono essere autenticati, quale IMO è ciò che l'OP sta chiedendo. Credo che ci possa essere una classe migliore per Authrorization, dato che tu e altri avete mentioend 'SecurityException'. –

Non sono d'accordo con la tua interpretazione. MSDN dice che queste eccezioni sono usate "quando l'autenticazione fallisce per un flusso di autenticazione", cioè durante il processo di autenticazione del client. La mia lettura della situazione dell'OP è che il processo di autenticazione è già stato completato e deve decidere se autorizzare un utente anonimo o autenticato. – Joe

Per evitare di reinventare la ruota, userei PrincipalPermission.Demand o PrincipalPermissionAttribute.

A SecurityException verrà generato per te se la richiesta non riesce.

Se si vuole lanciare esplicitamente un'eccezione piuttosto che usare PrincipalPermission.Demand, si potrebbe prendere in considerazione il riutilizzo del tipo esistente System.UnauthorizedAccessException, che è descritto in MSDN come:

L'eccezione generata quando il sistema operativo nega accesso a causa di un errore I/O o di un tipo specifico di errore di sicurezza.

È la tua app piuttosto che il sistema operativo che nega l'accesso, ma forse abbastanza vicino.

fonte

2013-03-19 10:35:55 Joe

IIRC, non dovremmo lanciare i derivati di SystemException da soli. Non sono intesi per uso generale. –

@ssg, non sono d'accordo. Lo stato delle linee guida per la gestione delle eccezioni MSDN (http://msdn.microsoft.com/en-us/library/seyhszts.aspx) "Nella maggior parte dei casi, utilizzare i tipi di eccezioni predefinite". – Joe

Vedo il tuo MSDN e genera il mio: "Non lancia System.Exception, System.SystemException, System.NullReferenceException o System.IndexOutOfRangeException intenzionalmente dal tuo codice sorgente." http://msdn.microsoft.com/en-us/library/ms173163.aspx –

Si potrebbe anche usare UnauthorizedAccessException per le violazioni di autorizzazione

fonte

2013-09-19 15:16:56

Il nome sembra buono, ma la documentazione dice "Un'eccezione UnauthorizedAccessException viene in genere generata da un metodo che esegue il wrapping di una chiamata API Windows." Per lo scenario presentato in questa domanda, ciò potrebbe potenzialmente essere fuorviante. È meglio lanciare un'eccezione personalizzata che riutilizzare un'eccezione framework destinata a un contesto completamente diverso. –

Penso che la parola chiave in quella osservazione MS sia "tipicamente" che suggerisce che il testo da seguire sia un esempio. Se dovessi esaminare un codice che ha rilevato una violazione non autorizzata, penserei che sia stato effettuato un tentativo di accesso non autorizzato e non necessariamente uno di "un metodo che avvolge una chiamata API Windows". –

Quindi ora sto dividendo i capelli, ma PrivilegeNotHeldException eredita da UnauthorizedAccessException, il che significa che qualsiasi blocco try/catch che gestisce l'eccezione UnauthorizedAccessException cercherà di gestire quell'eccezione, che non è ciò che si vorrebbe accadesse. Questo è retorico e un po 'esagerato, ma se scrivessi un programma di chat e scoprissi uno spunto tra due partecipanti, potresti lanciare un ArgumentException? Non stai cercando di implicare la semantica intorno all'eccezione che non corrisponderebbe a quelle per cui l'eccezione originale era destinata o utilizzata da altri? –

Eccezioni .NET che posso eseguire per Non autorizzato o Non autenticato

risposta

Problemi correlati