oauth 認可はどのように設計されていますか?

タイトルにあるように、oauth認証を通じて、ユーザー名、ユーザーアバター、メールアドレスなどの基本情報が取得されます

その後のデザインはどうなりますか?

ユーザーテーブルのパスワードフィールドは空ではないに設定されており、ユーザー名は一意に設定されており、取得した情報を直接保存することはできず、openidテーブル内のユーザー外部キーは簡単ではありません。また、取得したユーザーアバターはローカルにダウンロードする必要がありますか？

返信内容:

タイトルにあるように、

oauth認証を通じて、ユーザー名、ユーザーアバター、メールアドレスなどの基本情報が取得されます

その後のデザインはどうなりますか?

ユーザーテーブルのパスワードフィールドは空ではないに設定されており、ユーザー名は一意に設定されており、取得した情報を直接保存することはできず、openidテーブル内のユーザー外部キーは簡単ではありません。また、取得したユーザーアバターはローカルにダウンロードする必要がありますか？

訂正: 次回の oauth 認証のバッチの後、取得されるユーザー情報は、ローカル システムではユーザー名と呼ばれず、「ニックネーム」と呼ばれる必要があります。

その後、ローカル システムで使用されるユーザー テーブルには影響を与えません。次のようなユーザー テーブルの外観として存在する必要があります。

ユーザーテーブル

user_id、ユーザー名、パスワード

user_openidテーブル

user_openid_id、openid、openid_type、user_id、ニックネーム、アバター、メール

認証ログインプロセスは大まかに以下のとおりです。具体的なニーズは、製品のビジネスロジックに従って決定されます。

QQ、Weibo、WeChat等で認証ログイン後に取得される情報

1. user_openid に openid が存在するかどうかを確認します。存在しない場合は、まず保存します。存在する場合は、ログインします。存在しない場合は、user テーブルに必要な登録情報を入力します。サードパーティのログインアカウントの登録とバインドへ

2. 通常、ユーザー センターには、segmentfault と同様に、他のサードパーティ アカウントをバインドできる場所があります

3. 上記の手順を完了すると、通常のユーザー名とパスワードのログインとすべてのサードパーティアカウントのログインをサポートできるようになります

4. ビジネスロジックに基づいて他のいくつかの詳細なシナリオを検討することもお勧めします

5. アバターを保存できるかどうかについては、通常、サードパーティのアカウントによって提供されるアバターのアドレスは期限切れになりません。製品に特定の問題が発生した場合は、さらに最適化できます

   。