.NET-Ausnahmen, die ich für Nicht autorisiert oder Nicht authentifiziert auslösen kann

Ich habe Teile des Codes, in denen ich eine Ausnahme auslösen möchte, wenn ein Benutzer nicht authentifiziert / nicht autorisiert ist.

Anstatt meine eigene NotAuthenticatedException und NotAuthorizedException zu schreiben, habe ich mich gefragt, ob es für diese nicht bereits einige C # -Standards gibt.

Ich kann mir vorstellen, dass viele Programme ähnliche Ausnahmen auslösen, und es wäre nicht sehr nützlich, wenn jeder wieder sein eigenes Rad schreibt.

c# exception authentication authorization

— Dirk Boer
quelle

Sie können SecurityExceptionfür beide Szenarien verwenden.

— Zacken

Was ist das Problem beim Auslösen einer neuen NotAuthorizedException? Wenn Sie der Meinung sind, dass es nicht ausreichend gekapselt ist, kapseln Sie es einfach in eine statische Klasse.

— Fendy

@Fendy Ziemlich sicher, dass er seine eigene NotAuthorizedException schreiben will, nicht den eigentlichen Code throw new NotAuthorizedException();...

— Anaximander

In asp.net verwende ich HttpException (401, "Unauthorized") bzw. meine eigene HttpUnauthorizedExeption (): base ((int) HttpStatusCode.Unauthorized, "Unauthorized") {} zur besseren Lesbarkeit

— Liero

@Liero warum HTTP-Ausnahmen auslösen, wenn dies eine Autorisierung auf Datenebene sein könnte? Zum Beispiel möchte Dirk möglicherweise eine NotAuthorisedException auslösen, weil der Benutzer keinen Zugriff auf die Datensätze eines bestimmten Kunden hat.

— Jacques

Antworten:

Verwenden Sie die C # AuthenticationException- oder InvalidCredentialException- Klasse.

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

— Darren
quelle

Ich denke nicht, dass diese Ausnahmen für eine fehlgeschlagene Autorisierung oder für einen nicht authentifizierten (anonymen) Benutzer geeignet sind. Sie sind für den Fall gedacht, dass ein Client ungültige Anmeldeinformationen vorlegt, was sich davon unterscheidet, dass überhaupt keine Anmeldeinformationen vorgelegt werden.

— Joe

Ich denke, AuthenticationException ist vollkommen gültig. Direkt von MSDN: Die Klassen lösen diese Ausnahme aus, wenn der Client oder Server nicht authentifiziert werden kann. Nach welcher IMO das OP fragt. Ich glaube, es gibt möglicherweise eine bessere Klasse für die Authrorisierung, da Sie und andere Mentioend haben SecurityException.

— Darren

Ich bin mit Ihrer Interpretation nicht einverstanden. Laut MSDN werden diese Ausnahmen verwendet, "wenn die Authentifizierung für einen Authentifizierungsdatenstrom fehlschlägt", dh während des Authentifizierungsprozesses des Clients. Ich habe die Situation des OP gelesen, dass der Authentifizierungsprozess bereits abgeschlossen ist und er entscheiden muss, ob er einen anonymen oder einen authentifizierten Benutzer autorisieren möchte.

— Joe

Authentifizierung ist keine Autorisierung. Man könnte sich beispielsweise als "gesperrter Benutzer" authentifizieren, wäre aber nicht berechtigt, die Site zu nutzen.

— Sedat Kapanoglu

@DarrenDavies Es tut mir leid, dass ich dachte, InvalidCredentialsException dient der Autorisierung, nicht der Authentifizierung. Deshalb wollte ich darauf hinweisen, dass zwei Begriffe unterschiedlich sind. OP könnte das aber immer noch denken. Die Art, wie er die Frage schrieb, impliziert dies.

— Sedat Kapanoglu

Sie können auch UnauthorizedAccessException für Berechtigungsverletzungen verwenden

— Gruff Bunny
quelle

Der Name klingt gut, aber in der Dokumentation heißt es: "Eine UnauthorizedAccessException-Ausnahme wird normalerweise von einer Methode ausgelöst, die einen Windows-API-Aufruf umschließt." Für das in dieser Frage vorgestellte Szenario könnte dies möglicherweise irreführend sein. Es ist besser, eine benutzerdefinierte Ausnahme auszulösen, als eine Framework-Ausnahme für einen völlig anderen Kontext wiederzuverwenden.

— G-Mac

Ich denke, das Schlüsselwort in dieser MS-Bemerkung ist "typisch", was darauf hindeutet, dass der folgende Text ein Beispiel ist. Wenn ich mir einen Code ansehen würde, der eine nicht autorisierte Zugriffsverletzung abgefangen hat, würde ich denken, dass ein nicht autorisierter Zugriffsversuch unternommen wurde und nicht unbedingt einer durch eine Methode, die einen Windows-API-Aufruf umschließt.

— Gruff Bunny

Jetzt teile ich zwar Haare, aber die PrivilegeNotHeldException erbt von UnauthorizedAccessException, was bedeutet, dass jeder Try / Catch-Block, der die UnauthorizedAccessException behandelt, versuchen würde, diese Ausnahme zu behandeln, was nicht beabsichtigt ist. Dies ist rhetorisch und etwas langwierig, aber wenn Sie ein Chat-Programm schreiben und einen Spat zwischen zwei Teilnehmern feststellen würden, würden Sie eine ArgumentException auslösen? Versuchen Sie nicht, eine Semantik für die Ausnahme zu implizieren, die nicht mit der übereinstimmt, für die die ursprüngliche Ausnahme bestimmt war oder von anderen verwendet wurde?

— G-Mac

Es ist zu beachten, dass der Grund, warum der Windows-API-Aufruf diese Ausnahme auslöst, normalerweise darin besteht, dass der Benutzer keine Berechtigung zum Zugriff auf eine Datei / einen Ordner hat. Es passt also immer noch zum Gesamtthema einer generischen, nicht autorisierten Ausnahme.

— Jonathan Allen

Ich bin mit @ G-Mac einverstanden. UnauthorizedAccessException scheint für dieses Szenario nicht richtig zu sein

— Woodbase

Um das Rad nicht neu zu erfinden, würde ich PrincipalPermission.Demand oder PrincipalPermissionAttribute verwenden .

A SecurityExceptionwird für Sie geworfen, wenn die Anforderung fehlschlägt.

Wenn Sie eine Ausnahme explizit auslösen möchten, anstatt sie zu verwenden PrincipalPermission.Demand, können Sie den vorhandenen Typ System.UnauthorizedAccessException wiederverwenden , der in MSDN wie folgt beschrieben wird:

Die Ausnahme, die ausgelöst wird, wenn das Betriebssystem den Zugriff aufgrund eines E / A-Fehlers oder eines bestimmten Sicherheitstyps verweigert.

Es ist eher Ihre App als das Betriebssystem, das den Zugriff verweigert, aber vielleicht nah genug.

— Joe
quelle

IIRC, wir sollten keine SystemException-Derivate selbst werfen. Sie sind nicht für den allgemeinen Gebrauch bestimmt.

— Sedat Kapanoglu

@ssg, dem stimme ich nicht zu. In den Richtlinien für die Behandlung von MSDN-Ausnahmen ( msdn.microsoft.com/en-us/library/seyhszts.aspx ) heißt es: "Verwenden Sie in den meisten Fällen die vordefinierten Ausnahmetypen."

— Joe

Ich sehe Ihre MSDN und erhebe meine eigene: "Werfen Sie System.Exception, System.SystemException, System.NullReferenceException oder System.IndexOutOfRangeException nicht absichtlich aus Ihrem eigenen Quellcode." msdn.microsoft.com/en-us/library/ms173163.aspx

— Sedat Kapanoglu

@ssg - ... und daher können Sie implizit andere integrierte Ausnahmetypen aus Ihrem eigenen Code auslösen.

— Joe

@ssg - Nun, es verbietet auch System.Exception, und dies kann eindeutig nicht für seine Derivate gelten.

— Joe