ASP.NETコアでの最適化のデフォルトエラー処理を無効にします

導入

.NET Webアプリケーションを構築する場合、の組み合わせを使用することが一般的です UseExceptionHandler そして UseStatusCodePagesWithReExecute あなたの中で Startup.cs ユーザーフレンドリーなエラーページを提供するには：

app.UseExceptionHandler("/errorhandler/500");
app.UseStatusCodePagesWithReExecute("/errorhandler/{0}");

これは、CMSソリューションを最適化する場合でも、シームレスに機能します。ただし、最近、カスタムAPIエンドポイントを含むプロジェクトに取り組んでいるときに警告を発見しました。 Optimizelyには、エラー処理に関する独自の隠された動作があり、慎重に構成されたパイプラインに静かに干渉する可能性があります。

問題：APIセグメントのカスタムエラー

APIルートがありました 意図的に ビジネスロジックに応じて、生のHTTPステータスコード（例えば、401）を返します（401）。予想される動作は、フレンドリーなHTMLエラーページではなく、実際のHTTP応答コードを返すことでした。

ただし、一度 UseStatusCodePagesWithReExecute APIエンドポイントのようなものであっても有効です /my/custom/api 傍受すると、APIが401を返したときにHTMLエラー応答になります。

したがって、条件付きロジックを追加しました。

app.UseWhen(
    context => !context.Request.Path.StartsWithSegments("/my/custom/api"),
    appBuilder =>
    {
        appBuilder.UseExceptionHandler("/errorhandler/500");
        appBuilder.UseStatusCodePagesWithReExecute("/errorhandler/{0}");
    });

これは機能します –生産に行くまで。

驚き：Optimizelyは独自のミドルウェアをフックします

驚いたことに、私たちのAPIは、本番環境でOptimizelyのカスタムエラーページをまだ返していました。掘り出した後、それを発見しました Optimizely CMSは、独自の例外とステータスコードの処理を自動的に登録します、構成するものに関係なく。

これはあなたが電話するときに起こります .AddCms()-具体的には、 .AddCmsUI() 次のサービスを内部的に登録します。

services.AddStartupFilter();

このフィルターは次のようになります：

public Action Configure(Action nextAction)
{
    return app =>
    {
        if (app.ApplicationServices.GetRequiredService().IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }
        else
        {
            app.UseStatusCodePagesWithReExecute("/Util/Errors/Error{0}");
            app.UseExceptionHandler("/Util/Errors/Error500");
        }

        nextAction(app);
    };
}

だから、Optimizely いつも それ自体のエラーハンドラーのワイヤー – あなたの後。

ソリューション：スタートアップフィルターを取り外します

この動作を無効にする公開構成はありません。クラスはです internal、そのため、オーバーライドまたは構成することはできません。私たちは自分自身でサービスコレクションからそれを削除する必要がありました：

var errorStartupFilterServiceDescriptor = services
    .FirstOrDefault(descriptor => descriptor.ImplementationType?.Name == "ErrorsStartupFilter");

if (errorStartupFilterServiceDescriptor != null)
{
    services.Remove(errorStartupFilterServiceDescriptor);
}

これを早い段階で行うことによって ConfigureServices、Optimizelyのエラーハンドラーが注入されないようにするため、再びパイプラインを完全に制御できます。

最終的な考え

これはその1つです 「フレームワークマジック対開発者コントロール」 状況。すべてが地元で機能しているように見えるので、見逃すのは簡単です。生産が紛争を暴露するまで。

うまくいけば、これは誰かに数時間のデバッグを節約するでしょう！