ここのドキュメントの例をBlazor Webassembly プロジェクトに変換することにより、netstandard 2.0 に基づいて構築された Dropbox.Api dotnet SDK を使用しようとしています。PKCEOAuthFlowクラスがプライベート メンバーCodeVerifierを使用し、PKCE フローを実装するという事実に問題を絞り込みました。CodeChallengeこれらのプライベート メンバーは、コンストラクターでのみ生成および設定されます。これは理にかなっています。
だから、ここで私が立ち往生しているのが具体的です.Dropboxがアプリにリダイレクトした後に呼び出そうとしたときに同じでなければならない、1回だけ生成された正確なオブジェクトを保持するにはどうすればよいですか?CodeVerifier/CodeChallengeProcessCodeFlowAsync
私は次のことを試しました：
- メインタブが開いたままになるように、ドロップボックス認証 URL を新しいタブで開きます。これは、Dropbox がユーザーをリダイレクトしても新しいタブにとどまり、私のオブジェクトは最初のタブでしか生きていないため、失敗します。
- クラスを作成し、inside
ILoginServiceを実行してシングルトンとしてページに挿入しますが、常に新しいクラスを取得します。これが失敗する正確な理由はわかりませんが、ユーザーを Dropbox に送信すると Webassembly アプリ全体が範囲外になり、リダイレクト後にとにかく新しいアプリを作成する必要があると思います。builder.Services.AddSingleton<ILoginService, DropboxLoginService>();Program.csILoginService - また、静的コンストラクターに静的メンバーを設定して、
DropboxLoginServiceクラス全体を作成しようとしました。また、この方法を行うたびに、おそらく 2 と同じ理由で、新しいオブジェクトが作成されます。staticPKCEOAuthFlow - . _
Blazored.SessionStorage_CodeVerifier_CodeChallenge - これはまだ試していません - オブジェクト全体を何らかのバイナリ形式でシリアル化し、base64 文字列をセッション ストレージに保存して後で取得できる可能性があると思います。ただし、PKCE の要点は機密情報を含む信頼できないストレージを回避することであることを考えると、これはセキュリティ ホールのように感じられます。勇敢なハッカーがそのオブジェクトに到達し、何らかの方法で私のユーザーを MITM する可能性があるため、基本的にセキュリティが無効になります。基本的に、アプリ シークレットをどこかに保存して通常の OAuth2 に戻すよりも安全ではありません。
私はこれを複雑にしすぎていますか？PKCEOAuthFlowフローの最初から最後まで、アプリからの 2 つのリダイレクト -> Dropbox -> アプリに戻るまで、オブジェクトをメモリに保持する方法はありますか? この質問は Dropbox を超えて、Blazor Webassembly の OAuth2 + PKCE フロー実装、または実際にはサーバーレス SPA または PWA に適用されると思います。