第三部の詳細設計は基本的にほぼ同じで（あとは難しくないので後で追加します）、ビジネスロジックに沿ってコードを開発していきます。コードを書くのは簡単ですが、ビジネスロジックを組み合わせて美しいコードを書くことが前提ですコード仕様だけでなく、呼び出しが適切かどうか、依存関係が厳密かどうか、ロジックが合理的かどうかも考慮する必要があります、およびデザインが環境にやさしく簡潔かどうか。

そのため、まずショッププロジェクトの開発アイデアを学び、その利点を分析し、欠点があるかどうかを検討します. もちろん、私たち自身の理解が完全に正しいとは限りませんが、それについて考えなければ決して正解を知ろう！

同時に、キーポイントを区別する必要があります.すべてを詳細に分析する必要はありません.一般的な追加、削除、変更、およびクエリロジックと同様に、明確に説明するのが良いです.複雑な場合は、ログインロジック、支払いロジックなど、コード開発としていくつかのロジックが必要になることがよくあります。

総合的に分析する必要があるため、基本的で関連性の低い分析から始め、NO3-2 界面分析のロジックに従って大まかな方向性を決定します。

一般的な方向は次のとおりです。

1. 全体的なニーズのため、最初にシステム設定を解決します; [例: ロジスティクス、ゾーニング、構成など、主に運用側またはシステム]

2. 次に、会員の基本的な管理と店舗の基本的な管理を解決します [会員のログイン、登録、変更、店舗の申請、管理など、すべて 3 つの端末が関係します]

3. 次に、商品管理、ショッピングカート管理、およびプロモーション管理の解決に着手します [この 3 つの部分は非常に複雑であり、多くのビジネスを含みます。また、3 つの部分は相互に関連しているため、一緒に検討する必要があります。 ]

4. 最後に、残りの小さなモジュールを解決します. 結局、ほとんどのモジュールは最初の 3 つのモジュールに関連しています (たとえば、メンバー評価、ニュース、配信なども 3 つの端末に関連しています)。

分析の内容には、一般的に次のものが含まれます。

業務分析【まず解決すべき業務を分析し、業務に応じたコードの書き方を考える】

ビジネスクラス間の関係 [関連する主要なクラス間の関係を分析します。これは、ビジネスの理解とコード設計アーキテクチャのクリアに役立ちます ~]

コードの書き方 [主要なメソッドロジックの主要な記述を選択し、コーディングのアイデアを吸収する]

サードパーティ製ツール [使用したツールとその使用理由を記録]

上記の分析は表裏に分かれていませんが、やはり通常の開発プロセスとは明らかに違うショップシステムを分析したいのです。事業分析は以前に大部分を分析したので、必要がなければ飛ばします. 事業カテゴリ間の関係を分析する必要があります. 一部、プロモーションなど、以前に簡単に分析したこともあります. コード作成は、ビジネスクラス間の関係のアイデアをコードに実装することであり、一部のサードパーティツールはビジネスに影響を与え、一部はサードパーティのログイン、支払い、hutool ツールなどの単純なショートカットツールです。の上。

OK、すべての考えは終わったので、メンバーログインから始めませんか~~~~~~~~~~~~~~

A1. サードパーティプラットフォームの認証ログインロジック (理解する必要があります)

承認されたログインにはサードパーティのツールを使用する必要があるため、システムに追加する前に、その使用ガイドラインを理解する必要があります。

率直に言えば、サードパーティのプラットフォームでユーザーの情報を取得し (一意のユーザー ID が必要です)、この情報を当店のプラットフォームのユーザーとバインドして、ログインできるようにすることです。サードパーティを介したショッププラットフォーム。

したがって、重要なポイントは、第三者から許可されたユーザー情報を取得する方法を知ることです。

理解する前に、どのサードパーティのログイン方法が必要かを整理してから、必要なログイン方法に従って実際の使用を理解しましょう〜

PC側ではユーザー名とパスワードでのログイン、携帯電話番号でのログイン、この2つが登録されているのでまとめて
PC端末、モバイルアプリ/スモールプログラムのスキャンコードでログイン
PC端末、QQ認証ログイン
PC 側では、WeChat がコードをスキャンしてログインを認証します
WeChatアプレット端末、WeChat認証+携帯電話番号認証ログイン
WeChatブラウザ、WeChat認証ログイン
モバイルブラウザ、ユーザー名とパスワードによるログイン、携帯電話番号によるログイン
モバイルブラウザ、QQ認証ログイン
APP 端末、ユーザー名とパスワードのログイン、携帯電話番号のログイン
APP側、QQ認証ログイン
APP側、WeChat認証ログイン

上記の緑色のものは、サードパーティの承認が必要なログイン方法であり、残りはプラットフォームのログイン方法です.

B1.WeChat認証方法

WeChat の場合、 WeChat 開発プラットフォームがあり、多くの製品 (ミニプログラム、公式アカウント、オープンプラットフォーム、ミニゲームなど) の認証ガイドを提供します。ミニプログラムとオープンプラットフォームを理解する必要があります。

小さなプログラム端末があるため、小さなプログラムメソッドが必要です。小さなプログラムのAPIを直接使用して、必要なユーザー情報または携帯電話番号を取得できます。

オープンプラットフォームの必要性は、PC 側での WeChat コードスキャンの承認と、APP 側/WeChat ブラウザー側での WeChat クライアントの承認があるためです. 彼が提供する API インターフェイスを呼び出すには、オープンプラットフォームによって承認された appid とシークレットが必要です, そして最終的に私たちが望むものを手に入れます. 必要なユーザー情報; そしてオープンプラットフォームはウェブサイトアプリケーション, モバイルアプリケーション, サードパーティプラットフォームなどに分かれています. ウェブサイトアプリケーションとサードパーティプラットフォームのみを使用する必要があります.

C1. WeChat アプレット

WeChat アプレットの認証ロジックは、WeChat アプレットコンポーネントの API に基づいており、つまり、アプレットのフロントエンドで携帯電話番号などの認証ユーザー情報を取得します。時間は暗号化され、WeChat パーティーを呼び出す必要があります. インターフェイスはコード値を取得し、それを復号化して電話番号を取得します.

資料を読めば分かりやすいのですが、以下の携帯電話番号資料の取得方法は新しい方法ですのでご注意ください！そしてショップ企画は旧バージョンのメソッドを使っています！! !

新しいバージョンのロジック:

コンポーネントを介して携帯電話番号を取得するための動的トークンコードを取得し、access_token およびコードを介して HTTPS getPhoneNumber インターフェイスを呼び出すと、インターフェイスの応答で携帯電話番号情報が返されます。とても便利。

古いバージョンのロジック:

暗号化データ encryptedData と暗号化アルゴリズムの初期ベクトル iv を取得し、WeChat が提供する暗号化データ復号化アルゴリズムに従って復号化し、携帯電話番号情報を取得します。不便なことに、復号化は最初にユーザーの sessionKey を取得する必要があり、WeChat が提供する復号化アルゴリズムも使用する必要があります。

次の図は、ドキュメントの新しいバージョンとドキュメントのアドレスを示しています。

WeChat Mini Program Authorized Mobile Number Login: Get Mobile Number | WeChat ドキュメントを開く

携帯電話番号取得インターフェース | WeChat オープンドキュメント

古いバージョンのドキュメントとアドレス:古いバージョンの電話番号を取得 | WeChat オープンドキュメント

C2. WeChat オープンプラットフォーム

オープンプラットフォームの承認ロジックは、Web サイトアプリケーションとサードパーティプラットフォームのみを参照します. それらの承認ロジックは OAuth2 に基づいており、どちらも承認コード承認モードをサポートしているため、手順は似ています:

1. 获取code
2. 通过 code 换取 accesstoken
3. 然后根据 accesstoken 进行接口调用，获取用户基本数据资源或帮助用户实现基本操作。

WeChat ウェブサイトアプリケーション認証ログイン: ウェブサイトアプリケーションウェブサイトアプリケーション WeChat ログイン開発ガイド | WeChat オープンドキュメント

WeChat サードパーティプラットフォーム認証ログイン: サードパーティアプリケーションが公式アカウントに代わって Web ページ認証を開始 | WeChat オープンドキュメント

C3. WeChat AppID、openid、unionid (知っておく必要があります)

WeChat 認証を使用するための重要なポイントの 1 つは、WeChat で認証されたユーザー情報を取得する必要があることです. ユーザー情報には一意のユーザー識別子が必要であり、変更することはできません. ユーザー情報が毎回一貫していることを保証する必要があります.ユーザーが認証することで、当店のプラットフォームがユーザーIDを介してバインドされたメンバー情報を見つけることができます~~~

次に、openidとunionidはユーザーの一意の識別子ですが、違いがあります。下の図を見て理解してください~~

さまざまな種類の ID の基本概念の紹介 | WeChat オープンドキュメント

上の図から、openid と unionid の違いを理解できます。

さまざまなビジネスに応じて、さまざまな方法で使用できます。たとえば、次のようになります。

ビジネス 1: プロジェクトには複数のアプリケーションがあり、各端末の承認されたログインがこのプラットフォームの同じアカウントを指していることを確認する必要があります。

設計 1: (1) サードパーティのプラットフォームを使用して複数の端末を関連付け、任意の端末で WeChat ユーザーによって承認されたユニオン ID を取得し、プラットフォームのユーザーにバインドします。関連するアカウントを unionid で検索; (2) openid を直接使用することもできます. ユーザーが最初に認可するとき, どちらの端で, 彼はプラットフォームのユーザーにバインドする必要があります. 特定の端で一度バインドした後, ユーザー再認証後に見つけることができますが、各端末が最初にログインするときに一度バインドする必要があります。

ビジネス 2: プロジェクトには APP 側のアプリケーションのみがあり、プラットフォームを登録する必要はなく、ログインには WeChat 認証のみが必要です。

設計 2: (1) openid を直接使用し、ユーザーはアプリが最初に承認されたときに直接ログインし、その後、ログインするたびに直接承認し、ユーザー情報をバインドする必要はまったくありません ~

B2.QQ認証方法

QQには、 Tencentオープンプラットフォームもあり、さまざまなサービスプラットフォーム、アプリケーション開発プラットフォーム、コンテンツ開発プラットフォーム、QQ開発プラットフォームなどもあります. アプリケーション開発プラットフォームを理解する必要があるだけです。

C1. アプリケーション開発プラットフォーム

アプリケーション開発プラットフォームでのアクセス方法は、さらにモバイルアプリケーション、モバイルゲーム、PC アプリケーション、および Web サイトアクセスに分類されます。Web サイトへのアクセスに重点を置いており、QQ ログインも OAuth2.0 に基づいています。QQ ログイン OAuth2.0 は、Web サイトアクセスとモバイルアプリケーションアクセスをサポートします。

この 2 つのアクセス方法は、QQ が提供する SDK を使用することができ、OAuth2.0 プロトコルに従って独自に開発することもできます.ショッププラットフォームは、プロトコルに従って独自に開発された 2 つ目のプラットフォームです。つまり、この 2 つのアクセス方法は同じものと同等です (これも便利すぎる~~~)

QQ は認証コード認証モードもサポートしているため、手順は似ています。

Step1：获取Authorization Code
Step2：通过Authorization Code获取Access Token
Step3：（可选）权限自动续期，获取Access Token
Step4：使用Access Token来获取用户的OpenID

次の写真と文書のアドレス:

QQ ウェブサイト、モバイルアプリケーション認証ログイン: 開発戦略_サーバー側テンセントオープンプラットフォーム

/oauth2.0/authorize と /oauth2.0/show の違いウェブサイトアクセス QQ ログイン時の注意事項 - 見てみる

C3.QQ の AppID、openid、UnionID (知っておく必要があります)

もちろん、QQ によって承認されたユーザー情報には、openid である一意のユーザー ID も必要です。詳細については、ドキュメントを参照してください。

1 つには、QQ は、申請が必要な一意の UnionID を取得するために、さまざまなアプリケーションのアプリ ID も提供します。

Tencent オープンプラットフォームの概念と用語

QQ Interconnection UnionID Open Business セルフサービス処理ガイド—QQ Interconnection WIKI

B3. サードパーティプラットフォームの承認済みログインと独自プラットフォームのログインの論理的な統合を考える (スキップ可能)

C1.論理的思考

この論理的思考を書き留めて、頭をすっきりさせてください。

まず、プラットフォームがサードパーティのログインを統合する必要がない場合、プラットフォームはユーザーのアカウント情報を記録して保存する必要があります.最も基本的なものはアカウント番号とパスワードです.アカウント番号はユーザー名または携帯電話にすることができます番号であり、一意である必要があります。この方法でのみ、ユーザーがログインするたびに同じアカウントとそのアカウントに関連付けられたデータを開くことが保証されます。

しかし、サードパーティのプラットフォームを使用してログインと認証を行う場合、プラットフォームはユーザーアカウント情報を記録して保存する必要があるのでしょうか? これは、特定のビジネスに応じて開発されます。この時点で 2 つのオプションがあります。

解決策 1. プラットフォームがサードパーティのアプリケーションを使用してログインおよび承認した後、サードパーティのユーザー情報に従ってレコードをアカウント情報として保存し、次回サードパーティの承認を通じてログインするときに、ユーザー情報に基づいてアカウントを検索し、ログインします。

[このソリューションでは、サードパーティのユーザー情報にプラットフォームの一意のアカウント識別子 (ユーザー名や携帯電話番号など) が含まれていない場合、サードパーティのユーザー識別子に基づいて新しいアカウントが作成され、ユーザーはまた、ユーザー名/携帯電話番号 Number を渡してメンバーアカウントを登録します。これにより、2 つのアカウントが生成され、最終的に同じ人が複数のアカウントを持つ可能性があります。! 】

解決策 2. プラットフォームがサードパーティアプリケーションを使用してログインおよび承認した後、サードパーティのユーザー ID をプラットフォーム上の既存のアカウントにバインドします。アカウントが検索され、ログインします。

[このソリューションでは、サードパーティプラットフォームがユーザーのログインを承認する場合、プラットフォームのアカウントにバインドする必要があります。これにより、ログインにどの方法を使用しても、同じユーザーは 1 つのアカウントしか取得できません。最後に、同じユーザーが持つアカウントは 1 つだけです。! 】

質問に戻りますが、プラットフォームはまだユーザーアカウント情報を記録して保存する必要がありますか? 具体的なビジネスを見てみましょう.上記の2つのソリューションは最も絶対的なものではなく、一般に使用されている2つのソリューションにすぎず、ビジネスと実際の開発に応じて細分化できます.

一般的に言えば、オプション2の方が合理的であり、同じユーザーが複数のアカウントを生成するべきではないため、ユーザー自身が混乱します~~~~~~~~たとえば、特定のWebサイトでは、携帯電話番号を使用して登録しますアカウントを作成してから VIP を購入し、翌日 WeChat 認証でログインしました。アカウントを開設したところ、アカウントが VIP ではないことがわかりました。この時点であなたは: emmmmmmm

C2. 例

現在、多くの大規模な Web サイトでは、CSDN、Code Cloud などのログインを承認するサードパーティプラットフォームが追加されており、これらはすべてスキーム 2 を使用しています。

例 1、コードクラウド Web サイトはソリューションを使用しています 2、コードクラウドは複数のログイン方法でログインできます。ログインを承認するときにコードクラウド自身のアカウントをバインドする必要があり、後でこのログイン承認方法を使用すると、アカウント情報は同じです。

例 2、CSDN の Web サイトもスキーム 2 を使用しており、複数のログイン方法でログインすることもできますが、第三者認証でログインすると、アカウントがバインドされているかどうかが判断され、バインドされていない場合は、ログインできません！csdn アカウントにログインしてサードパーティアプリケーションをアクティブにバインドし、後でこのログイン認証方法を使用すると、正常にログインして同じアカウント情報を取得できます。

注: WeChat サードパーティログインを除き、WeChat ログイン後、アカウントを直接見つけてバインドするか、アカウントを直接登録してバインドすることができます。なぜ？

まず、csdnのアカウント登録には携帯電話番号が必要で、登録が成功すると、メールアドレスとユーザー名を追加してログインできるようになります。

第 2 に、WeChat アプレットのサードパーティ認証ログイン方法は、ユーザーの WeChat の携帯電話番号を取得できます。

したがって、この方法でアカウントを直接見つけることができることは明らかです~~~~

B4.shop プラットフォームの B 側会員ログインの実際のロジック (要理解)

プロジェクトの開発ロジックはビジネスと実際の状況に応じて設計されますが、私たちは結局ショッププロジェクトを学んでいるので (ショッププロジェクトは特定のビジネス要件を提供していないため、知る方法がありません)、実際の開発ロジックはそれどころか、最初にショッププロジェクトの最終的な開発結果を知る必要があり、次に実際の開発ロジックを分析し、最後にビジネス要件を分析して設計を取得することを選択できます。【主な考え方は大まかに：要求設計、開発設計、コード開発】

C1. 実際のサードパーティとアカウントのログイン結果

ショップで提供したデモアドレスの結果を見てください。

はい、さまざまな認証ログイン方法で 6 つのアカウントが生成されます. 信じられない場合は、デモアドレスで自分でテストできます.

C2. 実際のサードパーティとアカウントのログインロジック

これはすべて、マスターブランチのソースアドレスとデモアドレスに基づいています。

まず、承認されたログイン方法がいくつあるかをリストします。

緑色の陰影は、承認されたログイン方法です。

PC側ではユーザー名とパスワードでのログイン、携帯電話番号でのログイン、この2つが登録されているのでまとめて
PC端末、モバイルアプリ/スモールプログラムのスキャンコードでログイン
PC端末、QQ認証ログイン
PC 側では、WeChat がコードをスキャンしてログインを認証します
WeChatアプレット端末、WeChat認証+携帯電話番号認証ログイン
WeChatブラウザ、WeChat認証ログイン
モバイルブラウザ、ユーザー名とパスワードによるログイン、携帯電話番号によるログイン
モバイルブラウザ、QQ認証ログイン
APP 端末、ユーザー名とパスワードのログイン、携帯電話番号のログイン
APP側、QQ認証ログイン
APP側、WeChat認証ログイン

このロジックはログインアカウントに基づいており、新しいアカウントは生成されないため、最初に 2. スキャンコード登録のロジックを抽出します。1.7.9. それらはすべて同じプラットフォームアカウントのログイン方法を使用します (コードはすべて同じものを使用するため)。

このうち、3.と8.のQQログインはアカウントを生成し（コードが同じものを使用しているため）、5.と1.のログインはアカウントを生成します（ロジックが同じため）。

したがって、ログインメソッドのロジック (コード開発ではありません!!! コード開発については、c3 を参照してください) については、最終的に次のことに注意することしかできません。

PC端末、ユーザー名・パスワードログイン、携帯電話番号ログイン、WeChatアプレット端末、WeChat認証＋携帯電話番号認証ログイン
PC端末、モバイルブラウザ端末、QQ認証ログイン
PC 側では、WeChat がコードをスキャンしてログインを認証します
WeChatブラウザ、WeChat認証ログイン
APP側、QQ認証ログイン
APP側、WeChat認証ログイン

一つ一つ分析していきましょう。

1.については、ショッププラットフォームのメンバーアカウントは、ユーザー名と携帯電話番号を通じてユーザーの一意の識別子を決定し、携帯電話番号でログインすると、携帯電話番号を使用して直接登録できます。WeChatアプレット端末がログインを承認すると、WeChatユーザーの携帯電話番号が最終的に取得されるため、メンバー情報は最終的に携帯電話番号を介して取得されるため、これら2つの方法の最終的な操作は同じアカウントです〜

2.については、モバイルブラウザとPCの操作コードが全く同じ、つまり操作するappidが同じなので、取得するユーザーのopenidも同じなので、そのアカウントは最終的に関連付けられたものも同じです〜

では、なぜ 5. と 2. は違うのでしょうか? 2 つのログイン方法は最終的に異なるアプリケーションを操作するため、appid は同じではなく、最終的に取得したユーザーの openid も同じではないはずなので、unionid はどうでしょうか。これら 2 つのアプリケーションが同じ開発アカウントにバインドされているかどうかはわかりませんが、ソースコードには unionid と openid のバインドロジックが含まれていますが、デモアドレスには 2 つのアカウントが示されているため、unionid は一貫していないため、最終的に関連付けられたアカウントは次のとおりです。同じではありません〜

3. 4. 6. については、3 つのログイン方法は最終的に別のアプリケーションで動作するため、appid は同じではなく、最終的に取得したユーザーの openid も同じではないはずなので、unionid はどうでしょうか。上記のロジックと同様に、同じ開発アカウントの下にある必要はないため、最終的なリンクされたアカウントは同じではありません〜

以上がロジックですが、具体的な開発コードはどうでしょうか。コードインターフェースを開発するためのログイン方法ですか？そんなことは絶対にありません、似たようなプロセスがあれば、コードロジックを最小限に抑えて開発します〜

C3. 実際のサードパーティおよびアカウントログインコードの開発ロジック (主に同様の開発ロジックを分析して、低品質のコードを減らします)

まずはソースコードのログインメソッドの開発ロジックを列挙して、詳しく分析してみましょう

コード開発ロジックに従って、shop プロジェクトのメンバー側は次のように分けることができます。

パソコン側
WeChatミニプログラム
WeChat H5端末
モバイルH5端末
アプリ側

このうち、pc エンドは vue フレームワークを使用したフロントエンドコードであり、残りの 4 つはuni - appフレームワークを使用したフロントエンドコードであり、コード内のエンドごとに異なるログイン方法を区別しています。

バックエンドはすべて同じコードセットです。

コード開発ロジックによると、各エンドの開発コードはいくつかのタイプに分けることができます (主にバックエンドを区別します。最終的なフロントエンドはインターフェイスを呼び出してログインロジックを実現し、フロントエンドに関連するページを配置するためです)。最後に）：

ユーザー名とパスワードでログイン [各エンドのバックエンドコードは同じ]
携帯電話番号ログイン【各エンドのバックエンドコードは同一】
ログインするための PC 側のモバイルアプリ/小さなプログラムスキャンコード
WeChat アプレットでは、WeChat がログイン用の携帯電話番号を承認しました
WeChat H5 エンド WeChat 認証ログイン、モバイル H5 エンド QQ 認証ログイン、PC エンド WeChat スキャンコードログイン、PC エンド QQ スキャンコードログイン
APP側WeChat認証ログイン、APP側QQ認証ログイン

したがって、最終的にショップが開発したインターフェイスは次の 6 種類です。

1. 2. 3. のアプリケーションインターフェイスについては、cn.lili.controller.passport.MemberBuyerController【メンバーインターフェイス】を参照してください。

4. アプリケーションインターフェイスについては、cn.lili.controller.passport.connect.MiniProgramBuyerController【ミニプログラムログインインターフェイス】を参照してください。

5. 6. のアプリケーションインターフェイスについては、cn.lili.controller.passport.connect.ConnectBuyerWebController [Web 側でのサードパーティ認証共同ログイン] を参照してください。

具体的な開発内容は次回の記事に詳しく、アプリのインターフェースやロジックは以下に記します~~~~~

C4.現在のショップコードの小さな穴（ある程度小さな穴です）

WeChat アプレットでは、最終的な使い方は WeChat で承認された携帯電話番号でログインすることです。つまり、最初に携帯電話番号を取得してアカウントがあるかどうかを判断し、ない場合はアカウントを作成し、openid とバインドします。このアカウントへのユニオン ID、ここでの openid とユニオン ID に注意してください。つまり、2 つの関連付けがあります。

ただし、ユーザーが APP/H5/WeChat H5 を使用して WeChat 認証でログインした場合、アクセストークンとユーザー情報は WeChat コールバックインターフェイスの後で取得できますが、ユーザーの関連付けは最終的に openid に従って判断されます。! !

この論理的なプロジェクトではこれができないと思います. どのプラットフォームのユーザーが、さまざまな方法でログインして新しいアカウントを取得したいと考えていますか? データが散らばっていませんか? どのデータがどのアカウントによって操作されたかを一貫して覚えているのは誰でしょうか? とにかく、私は理解していません。. .

この部分は直接使用できません~~~~~ ソースコードの分析はこれで終わりです。変更したロジックを書き、時間があるときにコードを変更します。! !

A2.会員ログイン画面

B1.会員インターフェース

SMSログインインターフェースは、SMS認証コードインターフェースと結合する必要があります.SMS認証コードインターフェースは、cn.lili.controller.common.SmsControllerで見つけることができます.詳細なビジネス紹介は後で結合します~~~

登録ユーザー（ユーザー名、携帯電話番号）
ユーザー名とパスワードのログインインターフェイス
SMS ログインインターフェイス (このロジックは、SMS 確認コードインターフェイスと組み合わせる必要があります)
web-get mobile app/mini-program login QR code, web-QR code long-rotation training validation login, app/mini-program scan code, app scan code ログイン確認：同意/拒否
アカウントログアウトインターフェース

APP、モバイル H5 端末

APP、WeChat Mini Program、右上隅のコードをスキャンしてログインします

B2. WeChat アプレットのログインインターフェイス

WeChat アプレットのフロントエンドコードは、ユーザーが承認した携帯電話番号とユーザー情報を取得し、入力パラメーターとしてバックエンドインターフェイスを呼び出し、成功するとトークンを直接返します。アプレットの携帯電話番号を復号化する必要があるため、インターフェイスが選択されます。

したがって、これはそれほど複雑ではありません。

ミニプログラムログイン/自動登録

WeChatミニプログラム

B3. 第三者認証共同ログイン

ログイン方法には2種類あり、1つ目はサードパーティ共同ログイン方式で、サードパーティは主にoauth2.0のAuthorization code認証モードを利用しているため、統合するとサードパーティがプラットフォームインターフェースをコールバックするプラットフォームのフロントエンドページを指示し、プラットフォーム結果インターフェイスを呼び出して、応答結果トークンを取得します。2 つ目は、サードパーティのユーザー ID に従ってログインすることです。これはアプレットのロジックに似ていますが、開発が異なるため、シングルアウトインターフェイスでもあります。

Web上での第三者認証による共同ログイン

これらのほとんどは、通常のサーバー側アプリケーション (Web 側で一般的に使用される認証方法) と組み合わせて使用される OAuth2 Authorization Code モードです。

WEBで第三者信頼ログイン認証パス取得、第三者信頼ログイン統一コールバックアドレス取得、第三者信頼ログイン応答結果取得

モバイル端末での第三者認証による共同ログイン

このクラスは、主にモバイルアプリケーションまたは Web アプリと組み合わせて使用されます。

サードパーティのユーザー ID に基づくログイン (例: unionID、openid)

パソコン側

モバイルH5端末、APP端末、WeChat H5端末

[Lilishop Mall] No4-1. メンバー B 側のサードパーティログインの使用とバックエンドインターフェイス (WeChat、QQ など) を含むビジネスロジックコードの開発

No4ビジネスロジックのコード開発フェーズの説明

A1. サードパーティプラットフォームの認証ログインロジック (理解する必要があります)