5

アプリケーションが、ユーザーが何かを行うために認証/承認されていないことを発見した場合、それは予期しないことですか?

try {
    if (notAuth())
        throw new UnAuthException();
} catch (UnAuthException e) {
    Log . error(e);
    return false;
}

それが予想されるケースUnAuthExceptionなら、失敗した Auth が例外ではない場合、独自のフレームワークが非常に多くあるのはなぜですか?

4

2 に答える 2

4

範囲によります。

ビジネス ロジックレイヤーでは、「ユーザーが承認されていない/認証されていない」状況は例外的であり、たとえば (Java コード):

public String salutation(User user) {
  // may lead to a runtime exception if user is not authorized
  return String.format("Hello, %s!", user.getName());
}

（もちろんインターフェースです）の実装はUser、ユーザーの名前を返すか、 in をスローNonAuthenticatedExceptionしgetName()ます。

アクセス制御レイヤーでは、ユーザーの承認/認証ステータスは他の通常のステータスとして処理され、例外的な状況として扱われるべきではありません。

if (!user.isAuthenticated()) {
  httpResponse.addHeader("WWW-Authenticate", "Basic realm=\"secure content\"");
}
于 2012-09-09T08:19:17.597 に答える
1

はい、次の理由により、例外を介して authentication\authorizations を処理することをお勧めします。

1) 例外は、システムが好まない異常な状況であるため、例外処理を通じてその状況に対応しています。認証と承認の例外は、基本的にセキュリティ違反、つまりシステムの異常であり、違反に対応することをお勧めします。例外処理フレームワークは、違反\システム異常を報告するための一般的なメカニズムであるため、このフレームワークを使用してそのような状況に対応します。

これが、すべての一般的なフレームワーク (.NET を含む) に Auth がある理由です。エラーをカプセル化するための例外クラス。

于 2012-09-09T07:05:09.643 に答える