ブレザーを使用したソフトウェア調査の構築-パート5 -クライアントIP

私はBlazorを使用して小さな調査サイトを書くことに決めました.この一部は、Blakorを学ぶ言い訳です.
私はBlazorで学ぶように私は記事のシリーズとしてそれについてブログになります.
この一連の記事は、私が製品を使用することを学ぶことを通して行くように、むしろ私の思考プロセスであるBlazorのためのトレーニングコースであることを意図しません.
このシリーズの以前の記事:

Part 1 - State

Part 2 - Better State

Part 3 - Components

Part 4 - Render Mode

私が調査を実行している1つの懸念は、何度も何度も何度も反応を提供している一党によって動揺している結果を避ける方法でした.
これを見つける最も簡単な戦術は、応答者のクライアントのIPアドレスを記録して、報告段階の間にどんな悪いふるまいを探すことでした.
単純でなければならない理論では、クライアントのIPアドレスを記録し、レスポンスとともに保存します.

問題
通常はASP . NET用です.NETアプリケーションでは、クライアントのIPアドレスをHttpContextから取得します.
しかし、書き込み時には、HttpContextにアクセスできませんでしたthis Github issue .
これは将来のバージョン(おそらく. NET 5 )で解決されるだろうと思いますが、これは私に問題を残しました.

解決策
解決策は、実際には合理的に簡単だった-たとえそれがそれを達成するためにいくつかの余分なホップを取った場合でも.
まず最初に、Blafforアプリを起動する前に、関連する詳細を取得し、以下のようにします.

ホスト.京大理

        @{
            var requestDetails = new SoftwareSurvey.Models.RequestDetails
            {
                ConnectionIpAddress = HttpContext.Connection.RemoteIpAddress.ToString(),
                ForwardedIpAddress = HttpContext.Request.Headers.ContainsKey("X-Forwarded-For") ? HttpContext.Request.Headers["X-Forwarded-For"].ToString() : null
            };
        }
        <app>
            <component type="typeof(App)" render-mode="ServerPrerendered" param-RequestDetails="requestDetails" />
        </app>

だから私はBlazorアプリを起動する前に、私は標準的なASPを使用します.NETの機能を使用してモデルをRemoteIpAddress そして、X-Forwarded-For ヘッダ.The X-Forwarded-For 要求がプロキシを通して来たなら、ヘッダーは元のIPアドレスを含まなければなりません.
確かに防弾されていない間、それは応答をゲームする愚かな試みを捕らえるのに十分でした.
その後モデルを使用したparam-RequestDetails 属性表記.The param- Prefixは、App オブジェクトをモデルで設定します.

アプリ.剃刀

@inject SoftwareSurvey.Models.SurveyResponse _surveyResponse

...

@code {
    [Parameter]
    public SoftwareSurvey.Models.RequestDetails RequestDetails { get; set; }

    protected override Task OnInitializedAsync()
    {
        _surveyResponse.ConnectionIpAddress = RequestDetails.ConnectionIpAddress;
        _surveyResponse.ForwardedIpAddress = RequestDetails.ForwardedIpAddress;

        return base.OnInitializedAsync();
    }
}

モデルはApp 経由でRequestDetails プロパティ.私はその後、それらの詳細を使用して_surveyResponse 応答者の回答を追跡するために使用されるオブジェクト-そして最終的にazure cosmos dbに保存されます.

クエリ文字列
同様に、クエリ文字列値を記録するのにも便利なテクニックです.
私の自動テストの一環として、それがテストであることを記録したかったので、報告フェーズの間に後でフィルタリングすることができました.
これを達成するために?IsTest URLでマークされたURLで_surveryResponse オブジェクト-およびAzureコスモスDBに保存され、後で報告します.
それで、私は単に次のように加えましたRequestDetails HungホストにおけるモデルCSTML

IsTest = HttpContext.Request.QueryString.HasValue && HttpContext.Request.QueryString.Value.Contains("IsTest", StringComparison.InvariantCultureIgnoreCase)

そして、_surveyResponse オブジェクトをApp.OnInitializedAsync :

_surveyResponse.IsTest = RequestDetails.IsTest;

これは直接httpcontextを使用するよりも良いアプローチですか?
HttpContextはしばしば単体テストの問題の原因となります.特に、ユニットテストが既存のコードに追加されている場合.
私はしばしばhttpcontextのまわりにラッパーを作成して、直接HttpContext参照を避けるためにラッパーを注入するとわかります.
HttpContextを持っていないという制約は、直接参照に依存するのを避けるためには間違いなく良いことです.
データを効果的に扱うことによって[Parameter] ) あなたはApp クリーンであるため、テストを容易にします.
したがって、HttpContextがBlazorで利用可能になる前に、それは長くなるでしょう-今のところ、それは役に立つパターンでしょう.