我是 计算机学院
的电脑_喵o(≧∇≦o)~
好久不更新了,本喵为了赔礼道歉,我要高傲地给你们这些地球人拜个早年:祝你们新年快乐!大家都新年快乐!!o(≧∇≦o)~喵喵!!
2
1
9
今天转发一篇对学习编程的同学有点作用的文章。作为初学者的话,本喵还是觉得很有用的呢!~o(≧∇≦o)~喵!
PHP小白编程学习——第三方登录功能设计思维
文章作者:JM.Zack
作为一个学习编程的小白,这几天接触到了用户登录功能的设计与实现,为了加深记忆,我写了这篇文章,希望也能给许多学习的同学一些在思维上的帮助。
实验工具包括有:phpStudy ,Notepad++ 和 谷歌的Chrome
当然学习也是需要多些看看一些优秀的文章,为了尊重作者,我也在这里附上一个比较好的用户表设计的文章:
浅谈数据库用户表结构设计,第三方登录
https://www.cnblogs.com/jiqing9006/p/5937733.html
我记得以前玩网游的时候就是一个公司的游戏就需要注册一个公司的账号:梦幻西游要网易的邮箱账号,CSOL需要世纪天成的账号,CF需要QQ账号。注册账号就算了,每个公司对账号密码的格式要求还都不一样,那么对于我们玩家来说就是久不玩一个游戏就把那个账号给忘了,可以说是非常麻烦的一件事情。
随着社交软件使用的越来越频繁,门户登录的问题也开始渐渐变得越来越复杂:第三方登录,手机登录... 如果你现在新建一个网站,然后要用户输入一大堆的资料进行账号注册的话,那么用户使用量一定会是很低的,一个是不方便,时间成本高,二是应用拓展不强,应用粘稠度低。
现在的WEB建设,登录方式一般分3种:一是账号登录,二是第三方应用扫码登录,三是手机验证登录。
那么在数据库中,用户登录表和详情表的设计不能再像刚开始学编程那样:
id
username
password
用户名加上密码,解决简单需求,留个id作为其他表的外键。当然,那时候密码还可能是明文存储,好点的知道md5。
现在登录标配都是:用户名/邮箱/手机号登录,外加一系列微博、微信等第三方登录。表结构如下:
用户表
id
username
phone
…
用户第三方登录表
id
user_id
app_type
app_user_id
access_token
…
用户在输入框输入用户名/邮箱/手机号和密码之后,后台判断是邮箱、手机号或是用户名,再根据条件查询是否为特定用户。
这个表结构能够承载未来一段时间的业务需求了。如果说某天冒出了一个新的登录方式,比如身份证号登录,怎么办?继续在用户表加字段?我觉得不行。
无论username+password,还是phone+password,都是一种用户信息+密码的验证形式;再来理解第三方登录,其实它也是用户信息+密码的形式,用户信息即第三方系统中的ID(第三方登录一定会给一个在他们系统中的唯一标识),密码即access_token,只不过是一种有使用时效定期修改的密码。所以我们把它抽象出了用户基础信息表加上用户授权信息表的形式:
用户基础信息表 users
id
nickname
avatar
用户授权信息表 user_auths
id
user_id
identity_type 登录类型
identifier 标识
credential 密码凭证
登录类型:手机号 邮箱 用户名 或 第三方应用名称(微信 微博等)
标识:手机号 邮箱 用户名 或 第三方应用的唯一标识
密码凭证:站内的保存密码,站外的不保存或保存token
这个系统最大的特色就是,用户信息表不保存任何密码,不保存任何登录信息(如用户名、手机号、邮箱),只留有昵称、头像等基础信息。所有和授权相关(且基本前端展示无关的),都放在用户信息授权表,用户信息表和用户授权表是一对多的关系。说起来太抽象,列出来让大家理解清楚一点:
如果不是很复杂的网站需求,那么对于登录的判断可以这样写代码:
运行样例:
条件控制语句 switch...case 和 if...else 是可以进行互换的,这个大家按照需求来选择实现,我就不做过多讲述了。
数据库的话说说具体处理,用户发来邮箱/用户名/手机号和密码请求登录的时候,依然是先判断类型,以某用户使用了手机号登录为例,使用:
查找条目,如有,取出并判断 password_hash(密码) 是否和该条目的 credential 相符,相符则通过验证,随后通过 user_id 获取用户信息。
如果使用第三方登录,则只要进行以下判断:
-The End-
本文转载的文章都有原来作者的链接
如果侵权请联系我删除信息
作者 | JM.Zack
-- ପ( ˘ᵕ˘ ) ੭ 一个玩无止境的程序员 --
Good Good Study, Day Day Up!
o(≧∇≦o)~miao!
领取专属 10元无门槛券
私享最新 技术干货