サードパーティ API ログインを処理するにはどうすればよいですか? ！

現在、Tencent、Sina、Douban、Baidu などはすべてサードパーティのログインをサポートしており、サードパーティの Web サイトがユーザー情報にアクセスできるようになりました。これにより、この Web サイトのユーザーの登録手順は軽減されますが、サードパーティ API のユーザー情報の処理が少し面倒であることがわかりました。
一般に、ローカル Web サイトでは、サードパーティ経由で初めてログインするユーザーに対して、既存のローカル アカウントをバインドするか、ニックネームなどのローカル情報を入力するようユーザーに要求してローカルにバインドする必要があります。
私は当初、ローカル ユーザーが登録した mysql テーブルをサードパーティ API の mysql テーブルから分離しました。ローカル ユーザー テーブルは次のとおりです:

userid username password gender registertime loginnum registeraddress ip ...

サードパーティ API によって返される情報が異なるため、一部の基本情報のみを保存できます。ローカル テーブルと比較して、バインディング テーブルは次のように変更されています:

userid nick figureurl api_supplier ip loginnum  ...

ただし、このように、ユーザーは異なる方法で扱われ、個別に処理される必要があります。権限など、背後にあるものはたくさんあります。乱雑な。 。 。

csdner が mysql や php などのサードパーティのログインをどのように処理するかについて質問したいと思います。 。 。

ディスカッションへの返信(解決策)

ローカルテーブルとサードパーティのuseridカラムの値が競合する可能性があり、マージすることは不可能ですよね？ ！

ローカルテーブルとサードパーティのuserid列の値が競合する可能性があり、マージすることは不可能ですよね？ ！
ローカルテーブルの先頭に auto_increment id 列を追加しますが、一部の列は使用されないため無駄になる可能性があります

元々は独立したシステムでしたが、マージ後は「サードパーティ」が存在しなくなります

各 API各タワーは固有の値を返すので、個別のテーブルに分割する必要はありません

統合後は「サードパーティ」が存在しません。問題はサードパーティのログインです。将来、セッションを割り当てる必要があります。これをローカル ユーザー システムとは別に処理する場合、別のプログラム処理が必要になるのではないでしょうか。

各 API タワーは、その一意の値によって区別できる一意の値を返します。テーブルに分割する必要はありません

ローカル バインディングなしでサードパーティのログインのみを参照する場合、この「外部」アカウントはローカルポイント、スペース、その他のデータはありません。 。 。

少し変更してメンバーテーブルに挿入すると、ユーザー名がランダムになります

それを少し変更してメンバーテーブルに挿入すると、ユーザー名がランダムになります。アカウントをお持ちになります

ありがとう、それはわかっていますが、いつも不便だと感じています

何が不便ですか？サードパーティ ログインを使用するユーザーはサードパーティ ログインを使用するため、バインディングを使用する場合は、独自のユーザーや 2 つの方法を使用したいユーザーにとって便利であることも要因です。サードパーティのログインが使用されます。サードパーティのログインに問題がある場合、ユーザーがログインしたい場合は、バインドされたアカウントを通じてログインできます。これは、サードパーティのログインであるため、この Web サイトの使用には影響しません。パーティーログインではログインできません。

何が不便ですか？サードパーティ ログインを使用するユーザーはサードパーティ ログインを使用するため、バインディングを使用する場合は、独自のユーザーや 2 つの方法を使用したいユーザーにとって便利であることも要因です。サードパーティのログインが使用されます。サードパーティのログインに問題がある場合でも、ユーザーがログインしたい場合は、バインドされたアカウントを通じてログインできます。これは、サードパーティのログインであるため、この Web サイトの使用には影響しません。 -party ログインではログインできません。

プログラムに多くの変更を加える必要があると思いませんか? ！

まず見てみましょう

私はそれについて考えました。すべてのサードパーティ API ログインは、ユーザーがサードパーティ経由でログインすると、そのユーザーに thirdPartyAPIid が割り当てられます。もちろん、ローカル ユーザーのこの列の値は null です。これは扱いがはるかに簡単です。

ユーザー テーブル

userid username email password ... third_party_api_id

third_party_api テーブル

id userid username email ... provider

ユーザー テーブル third_party_api_id は third_party_api テーブルの ID に関連付けられているため、ログイン方法に関係なくユーザーの動作を制御できます。

はは、私がこれを長い間行ってきたので、問題はありません。プログラムを変更する必要はまったくありません。サードパーティのインターフェイスを介してログインするだけです。ローカルのものと同じ Cookie またはセッションです

笑、私がこれを長い間行ってきたアイデアに問題はありません。プログラムを変更する必要はまったくありません。サードパーティのインターフェイスを介してログインし、ローカルのものと同じ Cookie またはセッションを提供します。ありがとうございます。現在、さまざまな Web サイトで提供されているサードパーティのログイン インターフェイスの手順を調べています。