1

HttpConext オブジェクトには、標準の asp.net パイプラインの一部であるUrlAuthorizationModuleの承認チェックを無効にするために使用されるSkipAutorization プロパティがあります。

ImageResizer は、通常の asp.net パイプラインの外部でUrlAuthorizationModule.CheckUrlAccessForPrincipalを直接呼び出します。その結果、SkipAutorization プロパティは無視されます。

その回避策は次のとおりです。

protected void Application_Start(object sender, EventArgs e)
{
  // Ask ImageResizer not to re-check authorization if it's skipped 
  // by means of the context flag
  Config.Current.Pipeline.OnFirstRequest += 
      (m, c) =>
      {
          Config.Current.Pipeline.AuthorizeImage +=
              (module, context, args) =>
                  {
                      if (context.SkipAuthorization)
                      {
                          args.AllowAccess = true;
                      }
                  };
      };
}

ここでの外側の OnFirstRequest は、すべてのプラグインがロードされた後に AuthorizeImage サブスクリプションが発生していることを確認するためのもので、チェーン内で最後に実行されます。

実装に大きく依存するため、この回避策は好きではありません。たとえば、ImageResizer プラグインの読み込みが onFirstRequest から別の場所に移動された場合、壊れます。

これが ImageResizer 自体で修正されるとよいでしょう。InterceptModule の追加の Autorization チェックを次の行に沿ったものに変更することをお勧めします。

//Run the rewritten path past the auth system again, using the result as the default "AllowAccess" value
bool isAllowed = true;
if (canCheckUrl) try {
        isAllowed =  conf.HonourSkipAutorization && app.Context.SkipAuthorization 
                     || UrlAuthorizationModule.CheckUrlAccessForPrincipal(virtualPath, user, "GET");
    } catch (NotImplementedException) { } //For MONO support

それは適切でしょうか、それともより良い解決策はありますか?

質問の最後の部分では、私の使用例について説明します。読み取りは完全にオプションですが、このクエリがどのようになったかの見通しを示します。

asp.net アプリケーションには、pdf ドキュメントを提供する HttpHandler があります。URL とヘッダー (私は OAuth を使用しています) でドキュメント ID とセキュリティ情報を受け入れ、すべてのセキュリティ チェックを実行し、成功した場合はデータベースから pdf ドキュメント パスを取得し、ファイルは Response によってクライアントに提供されます。書き込みファイル。

PDFページのプレビューを画像として提供する必要があり、そのためにPdfRendererプラグインでImageResizeを使用しています。

残念ながら、ファイルハンドラーが機能するまでpdfのパスはわかりません。これは、ハンドラーが実行される前に（明らかに）PostAuthorizeRequestですべての魔法が発生するため、ImageResizerがリクエストに対応するには遅すぎます。

これを回避するために、HttpHandler を HttpModule として書き直しました。これは、BeginRequest で実行されます。承認チェックが失敗した場合、リクエストはその場で切断されます。問題がなければ、PathRewrite を使用して結果の pdf をポイントし、同時に適切な Content-Type およびその他のヘッダーを応答に書き込みます。同時に、context.SkipAutorization フラグを設定します。これは、web.config 構成に従って直接 URL を介して pdf ファイルにアクセスできないため、承認がスキップされない場合、パイプラインは PostAuthorizeRequest に到達することさえできないためです。この場合、必要なすべてのチェックがモジュールによってすでに実行されているため、承認をスキップしても安全です。

これにより、実行フローが ImageResizer に到達できるようになります。しかし、画像リサイザーは、pdf URL の承認を再確認することを決定します。上記の回避策を適用しない限り、これは失敗します。

この再チェックの根拠は何ですか？上記のシナリオでは、ImageResizer が処理する必要がある場合、提供する画像は URL に表示されるものではなく、認証チェックは asp.net パイプラインによって既に行われています。この再チェックはどのような場合に役立ちますか?

4

1 に答える 1

1

更新: ImageResizer の最新バージョンは HttpContext.SkipAuthorization ブール値を尊重するため、イベント ハンドラーは不要になりました。

あなたの回避策はまさにこれに対処する正しい方法であり、前方互換性があります。

再チェックが存在する理由

  1. URL の書き換えは非常に一般的であり、奨励されており、特定の ImageResizer プラグイン (FolderResizeSyntax や ImageHandlerSyntax など) によって実装されています。
  2. Authorize ステージの後に URL を書き換えると、UrlAuthorization を完全に回避できます。

ImageResizer はHttpContext.SkipAuthorizationを尊重する必要があります。おそらく将来のリリースに含まれるでしょう。

とはいえ、あなたの回避策AuthorizeImageは実際に私が提案するものです。SkipAuthorizationそれ自体よりも壊れやすいとは思いません。実際、将来 ImageResizer がイベントをどのように並べ替えるかに関係なく機能するはずです。

ImageResizer は、パイプライン内のイベントの順序を尊重します。PostAuthorize の前に承認が行われる V2 は正確です (ただし、BeginRequest 中に追加のフロントエンドのサイズ変更をサポートしたい場合は、PreAuthorize に移動できます)。

また、元の PDF を提供するために RewritePath を使用すると、WriteFile を呼び出すよりもはるかに効率的です。特に IIS6 以降では、お気づきかもしれません。

于 2012-11-27T23:16:55.890 に答える