始める前に、Web フェデレーテッドログインに関連するサードパーティのログインロジックはほぼ一貫しており、OAuth2.0 承認コード承認モードを使用することを説明します [このモードは通常、通常のサーバー側アプリケーションと組み合わせて使用されます ( Web側でよく使われる)認証方法)]なので、想像できる業務が多く、コードロジックで見ることができます〜

フェデレーテッド・ログインには、3 つのインターフェースが含まれます。例として、PC での WeChat コードスキャン認証ログインを見てみましょう。

最初に、ユーザーは PC のフロントエンドにある WeChat ログインボタンをクリックします。このとき、サードパーティの信頼できるログイン認証パスを取得するためのプラットフォームのインターフェイスが呼び出され、入力パラメーターのログインメソッド (WeChat PC、WeChat アプレット、 QQ など) が渡されます。このインターフェースは、サードパーティのログイン方法に応じて、対応するサードパーティの認証 API と、認証 API に必要な入力パラメーター (appid、scope など) を取得します。入力パラメーター、redirect_uri は platform.api (つまり、2. のインターフェース) のコールバックアドレスであり、状態はサードパーティがコールバックしたときに運ばれ、両方のパーティによる効果的な検証に使用されるため、一意であり、キャッシュに格納されます。次に、上記の情報に基づいて承認された URL にスプライスし、リダイレクトのためにフロントエンドに返します。
PC フロントエンドがそれを受信すると、認証 URL ページにリダイレクトされます. このページはサードパーティによって提供されます. このとき、ユーザーはコード/ログインアカウントをスキャンします. サードパーティが正常に認証されると、サードパーティはパーティはプラットフォームのコールバックインターフェイスを呼び出します。これは 1 の redirect_uri API アドレスです。入力パラメータコードと状態があり、コードはサードパーティによって定義され、状態はプラットフォームによって定義されます。このインターフェースでは、コードで accessToken を取得し、次に accessToken でユーザー情報 (openid など) を取得します。次に、openid に従ってバインドされたアカウントを取得し、アカウントが取得できた場合は、そのアカウントに基づいてログイントークンを作成します。アカウントが関連付けられていない場合は、openid に基づいて新しいアカウントを作成し、サードパーティを関連付けてから、アカウントに基づいてログイントークンを作成します。次に、状態をキーとして使用して、3..のトークンをキャッシュします。最後に、プラットフォーム PC のログインページに戻り、フロントエンドにリダイレクトし、パラメータの状態を渡します。【現時点では、フロントエンドはサードパーティであり、サードパーティはプラットフォームページにコールバックします】
サードパーティは、プラットフォームの PC 側のログインページをコールバックし、ページに状態パラメータがあるかどうかを判断し、サードパーティの信頼されたログイン応答結果取得インターフェイスを呼び出し、2. に従ってキャッシュされたトークン情報を取得します。状態に戻し、フロントエンドに返します。

上記のプロセスは、リダイレクトによっても完了します。

一言で言えば：

サードパーティのユーザー情報（つまり、一意の識別子）を取得し、ユーザー情報に基づいてバインドされたアカウントがあるかどうかを判断し、バインドされていない場合は、このアカウントのログイントークンを登録してキャッシュします。キャッシュされたログインを取得するにはトークン、そしてログインは成功です!

ビジネスの論理：

ビジネスロジックは上で見ることができ、非常に明確に説明されています〜

実際、特に複雑なロジックはありませんが、少し複雑です。

そこで質問なのですが、PC側のQQ認証、Alipay認証、Weibo認証などは全部そういうロジックなので、それぞれの再開発インターフェースに対応する必要があるのでしょうか？もちろん、同じようなコードが 1 セットだけあればよいというわけではありません。コードを無駄に書くのではなく、コードの再利用性を向上させることで、コードの保守性を向上させます。

次に、コードを適切に設計する必要があります。コードロジックを参照してください~~~

コードロジック:

1. サードパーティの Auth ログイン要求を処理する小さなモジュールである AuthRequest (最初に内部の関係図を確認できます)

さまざまなサードパーティのプロセスが類似していることはわかっているため、appid、appSecret、認証 URL など、サードパーティの構成情報が異なるという特別な点があります。内容が異なるものもあれば、さまざまな分野。次に、さまざまなサードパーティ情報を保存し、さまざまなサードパーティに従って使用する必要があります。

上記の側面から、サードパーティの Auth ログイン要求を具体的に処理する小さなモジュールを抽象化できます。ビジネスを満たすために。このモジュールには、次の情報の保存と送信が含まれている必要があります。

appKey、appSecret、redirectUri などのサードパーティの承認構成は、すべてのサードパーティ用であり、一部は共有され、一部はサードパーティによって使用されます。ここでの構成は設定に保存されます。
サードパーティ認可API、認可API、accessToken取得用API、ユーザー情報取得用APIなどはすべてサードパーティ向けであり、一部は共有されており、一部はサードパーティによって使用されています。

以下の事業の処理：

上記の 1. 2. の情報に従って、必要なリクエスト URL をスプライスします。つまり、承認 URL、ユーザー情報 URL などのパラメーターを API に追加します。
統一されたログインロジックを設定し、最初にコードを通じてアクセストークンを取得し、次にアクセストークンに従ってユーザー情報を取得します。

したがって、上記の結論に基づいて、ビジネスロジックと組み合わせて、次のモジュールのクラスの関係図を取得できます。思考の指示はすべて図の中にあります~~~

2. Web 側でサードパーティログインを具体的に処理するツールクラス ConnectUtil

それと、サードパーティの Auth ログイン要求を具体的に処理する上記の小さなモジュールとの違いは何ですか?

ConnectUtil ツールクラスは、共同ログインリクエストインターフェイスと共同ログインビジネスクラスを引き受けるツールクラスで、主に Auth ログインリクエストモジュールを介して構成情報を取得し、共同ログインビジネスクラス ConnectService を呼び出して、特定のプラットフォームサービスを処理します。ビジネス。

わかりました、中級者向けのツールです~~~

主な方法は次のとおりです。

AuthRequest getAuthRequest(String type) ログインにより、対応するサードパーティ認可リクエストオブジェクトを返します
void callback(文字列型, AuthCallback コールバック, ...) ログインコールバックメソッド
ResultMessage<Object> getResult(String state) 連携ログイン応答結果を取得する

1 は AuthRequest の協力のみを必要とし、3 は Cache の協力のみを必要とし、2 は次の共同ログインビジネスクラス ConnectService を必要とします。

3. 共同ログインビジネスクラス ConnectService

このクラスは、前回の記事で WeChat アプレットの認証ログインを扱ったときに登場したので、ここでのロジックは非常に単純です。共同ログインに特化した最後のビジネスクラスです。! !

これにはメンバー操作が含まれるため、このクラスはメンバービジネスクラス MemberService に注入する必要があります。

このクラスの主なアイデアは、サードパーティのユーザー情報に従って共同ログインサービスを運用することであることがわかります。

4. インターフェースからビジネスまでの関係図（最初に見ることができます）

5.キーコードの写真（ソースコードは含まれていません。多すぎて不便です）

ConnectBuyerWebController インターフェイス:

ConnectUtil :

上記のリダイレクトは、プラットフォームの特定のページ、できればログインページにリダイレクトし、保存されたトークンのキーに対応する状態パラメーターを渡すことであることに注意してください~~~一意の値を使用して、直接取得してくださいここでサードパーティの仮ログイン認証コードですが、名前は認証URLを呼び出す状態なので、とにかく注意してください~~~

[Lilishop Mall] No4-4. ビジネスロジックのコード開発 B会員側の第三者ログインの開発・Web側の第三者認証共同ログインインターフェースの開発

A1.会員共同ログインモジュール