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

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

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

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

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

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

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

user_openidテーブル

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

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

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

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

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

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

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

   。