关于用户登录注册的一些实践

虽然关于用户登录注册几乎是每个系统的标配,也是大多数教程里的经典样例。但实际工作中,我们还是时不时会被“用户”搞的焦头烂额。比如防止机器注册、oauth接入以及带来的用户账号合并问题、用户身份验证或身份标识、用户相关的表应该如何设计以应对未来各种扩展和可能性等等。

这里记录一些之前的设计和开发的经验。

用户是否一定要注册并登录

我个人非常反感打开一个网站或者App以后,还没搞清楚是做什么的时候就强制要求注册的。这种做法绝对是“好奇心杀手”,至少一半的人被这个动作挡在了外面,实在是不值得。我之前参与的项目,只要是可以最终能够获得用户的联系方式的,那么一定不需要用户注册以后才能使用功能。比较常见的情况是标准的电商网站,浏览和查看是不需要用户注册的,但是结算时就需要了,在我看来虽然比一上来就注册好一点,但还是有点“伤” – 用户都已经下决心购买了啊!用户结算时一般都会做两件事:填写联系方式、支付。这些都不需要用户ID这个东西,能联系到用户就已经很成功了,一定要用户填个注册表单吗?当然不排除是万恶的KPI。

不过不注册产生的一个问题是用户“返回”和订单跟踪时会需要额外的流程来,比如需要用户提供订单号来找回订单,甚至可能需要人工介入。

身份标识

即如何标识一个用户,常见的标识有:昵称、邮箱、手机号、OAuth授权ID。更多的标识建议没有特殊必要就不要收集了,一来涉及到个人隐私,二来这种数据需要更高安全要求的存储(前提是你没打算用来干坏事)。在bot还不是那么泛滥的年代,常常是一个昵称就可以了,但现在连邮箱都不行了,几乎都是手机号码起步。很多时候,一个手机号就对应一个用户,虽然现实并不是这样,但至少是比较靠谱。会产生多账号问题 – 因为有些人换号了或者有多个手机号,如果用户有合并账号asset(也就是账号的“资产”,比如余额、积分、优惠券等等)的需求,目前看貌似真不好搞,判断两个账号同一个人并不容易也会存在风险。

比较常见的还是基于手机号标识用户后,在进行手机号的更换绑定的流程,这样就成了“一个用户一个手机号”,也算是解决了问题。至于账号相关asset合并问题,就要视具体情况来定了。

多账号问题

举个极端的例子,当系统支持手机号、邮箱注册,同时支持Oauth登录时,如果没有任何限制,一个用户可能会用手机号、邮箱、各个Oauth各注册一个用户。这种情况带来的问题是用户会搞不清楚自己的订单在哪个用户里,相信我,有这种“糊涂”的用户。之前的一个经验是“关联”,比如,除了上述的标识以外,我们通常还会生成一个唯一的标识记到cookie里,同时useragent信息也可以部分的标识,geo信息,ip归属地,甚至再“玄”一点的用户行为模式。通过这些标识也可以进行账号是否属于同一用户的判断,此时再提供给用户合并账号的流程。

OAuth

OAuth现在也是标配了,大多数的OAuth的接入都不困难,所以接入的技术细节就略过了。之前的经验是用户和用户OAuth是一对多的。用户正常注册后,然后绑定各OAuth,这样之后通过OAuth登录就可以确定用户,这是最简单的情况。如果用户是先通过微博的OAuth登录,之后又正常注册的,也就是上面说的多账号问题了,除了上面的“关联”方法,另一种解决办法是针对这种用户鼓励再进行手机号或邮箱的注册。

经常见到,用OAuth登录跳转回来以后,马上要求用户进行手机号或邮箱注册的流程,虽然可以最快的完成绑定。但却失去了Oauth登录的便捷性,有点被“坑”的感觉 – 本来觉得注册麻烦,以后授权一下就可以搞定,结果授权完还是一样要注册。

用户表结构

也没什么花头,User表记录用户的基本信息,UserProfile记录用户的个人资料,UserAddress记录用户的地址,UserOauth记录用户的登录授权信息,UserCredit用户积分信息,UserXXX,总之就是尽量让User表纯粹,通过增加实体表来扩展。比较简单,就不细说了。

验证码(captcha)

验证码用来防止机器人进行表单提交,比较经典是12306的验证码。对这件事我是有点“悲观”的,因为永远都是道高一尺,魔高一丈。现在很多时候都是用了手机或者邮箱的动态验证码,或者类似微信换设备登录时选择好友头像,还有非常原始但有效的“注册预留问题”。相对来说类似微信这种根据账号的asset(微信的好友就是微信账号的asset)来进行验证,但这个又是和你的业务相关的,比如如果是滴滴打车,可能会让你选择你曾经在哪些城市使用过滴滴。

单纯的captcha真的没有卵用,看看满大街的注册机就行了,当可以cover成本的时候,甚至都可以人肉来做,搞captcha有啥用呢?