How is oauth authorization designed?

WBOY
Release: 2016-07-06 13:53:19
Original
738 people have browsed it

As mentioned, through oauth authorization, some basic information is obtained: user name, user avatar, email

What will the design look like after that?

The password field in the user table has been set to not empty, and the user name is set to unique. The obtained information cannot be directly stored , the user foreign key in the openid table is not easy to get. In addition, does the obtained user avatar need to be downloaded locally? Can anyone give me an idea? Thank you

Reply content:

As mentioned, through oauth authorization, some basic information is obtained: user name, user avatar, email

What will the design look like after that?

The password field in the user table has been set to not empty, and the user name is set to unique. The obtained information cannot be directly stored , the user foreign key in the openid table is not easy to get. In addition, does the obtained user avatar need to be downloaded locally? Can anyone give me an idea? Thank you

Correction: After the next batch of oauth authorization, the user information obtained is not called the user name. For the local system, it should be called "nickname"

Then it should not affect the user table used by the local system. It should exist as the appearance of the user table, similar to the following

user table
user_id, username, password

user_openid table
user_openid_id,openid,openid_type,user_id,nickname,avatar,email

The authorization login process is roughly as follows. The specific needs are determined according to the product business logic. There are many design methods

  1. Information obtained after authorized login from QQ, Weibo, WeChat, etc.

  2. Determine whether openid exists in user_openid. If it does not exist, save it first. If it exists, determine whether there is a user_id. If so, log in. If not, complete the registration information required for the user table. It is similar to registering and binding. Three-party login account

  3. Generally, there is a place in the user center where you can bind other third-party accounts, similar to segmentfault

  4. After completing the above steps, you can support normal username and password login and all third-party account logins

  5. It is also recommended to consider some other detailed scenarios based on business logic

As for whether the avatar can be saved or not, generally the avatar address provided by the third-party account will not expire. If you encounter specific problems in your product, you can optimize it

Related labels:
source:php.cn
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template