0

Authorize 属性に基づいて MvcSiteMapProvider を使用してきましたが、 から派生した新しいクラスを導入するまでは問題ありませんでしたAuthorizeAttribute。主な違いは、コンストラクターの署名にあります。

public MyAuthorizeAttribute(param RoleCode[] roles) {
    Roles = string.join(",", roles.Select(r => r.ToString());
}

そして... MvcSiteMapProvider は予期しない結果を示しました: でマークされたアクションのみが非表示にMyAuthorizeAttributeなりました。このコンストラクターを無効にすることで確認しました-コンストラクターにパラメーターを追加する前と同じようにすべてが行われました。また、params具体的ではありませんが、任意のパラメーター (イベント int) がそのような動作につながります。

MvcSiteMapProvider ソースから理解したように、承認属性をエミュレートするコードを発行しますが、外部コードによって生成されたアセンブリを保存することは不可能のようです。回避策があることは知っています-ある種の列挙可能なプロパティを使用しますが、コンストラクターパラメーターで機能させる方法について何か提案はありますか? MvcSiteMapProvider がそのように動作する理由を知っていますか?

4

1 に答える 1

0

そのため、デバッグに時間を費やした後、動的プロキシーという答えに気付きました。

AuthorizeAttribute問題は、MVC フレームワーク内でのリクエストの実行中に、 から派生したクラスがその作業をどのように実行するかを確認する簡単な方法がないことです。アクセス チェックに失敗した場合、例外をスローするもの、401 ステータス コードを返すもの、すぐにログイン ページにリダイレクトするものなどがあります。

しかし、MvcSiteMapProvides はそれを行います。次の回避策を使用します。

  • クラスが次の場合AuthorizeAttribute:
    • InternalAuthorizeかなり単純なクラスのインスタンスを作成します。
    • そこにすべてのプロパティをコピーし、
    • AuthorizeCoreブール値を返すメソッドを呼び出します。
  • そうしないと
    • 属性のタイプから派生したプロキシ クラスを生成し、
    • create instance, /// << ここで例外が発生します
    • そこにすべてのプロパティをコピーし、
    • AuthorizeCoreブール値を返すメソッドを呼び出します。

明らかなように、コンストラクターのパラメーターを認識するプロキシを作成するのは簡単な作業ではありません。もちろん、デフォルトのコンストラクターの不在に関する例外がスローされますが、空の catch 句によって消費されます。これは本当に悲しいことです。少なくとも 1 回のデバッグ トレースがあれば、数時間は節約できたはずです。

だから、最後に答え：

  • 明らかに、パラメーターのない属性コンストラクターを使用する必要があります (なぜそれがどこにも言及されていないのですか?)
  • カスタム ACL プロバイダーを作成します。IAclModuleインターフェイスを実装し、その中の独自の承認属性に関する知識を解き放ちます。
于 2012-10-20T12:57:44.907 に答える