Lyndon's Studio以前开发过几个版本的贴吧吧务应征系统、旅游管理系统、二手物品交易平台、面向SFer的邮箱申请系统等，现在还有大学的学生会招新管理系统。它们需要一个用户管理机制，如果让用户每个网站都注册一遍，是很繁琐的。事实上，现在市面上各种通过QQ、微信登录都是要解决这个问题。接入这些服务固然很简单，但对积累实践经验无好处。
我在吧务应征系统里用到了通过百度ID登录来为用户绑定百度账号，防止冒用百度ID来应征。
如图，用户需要通过百度提供的API使用百度账号登录，将其与自己的应征系统账号绑定在一起。
那么，首先我们需要单独建立一个数据库，用来存放用户信息，并通过一些API接口，用来与网站取得通信。
看一个实例：http://travel.lyndons.cn 这是旅游管理系统。
点击登录或注册，可以看到地址栏是api.lyndons.cn，通过api接口登录（SSL加密）。
以下我们将用户管理系统所在服务器称为服务端，将具体应用的承载网站称为客户端。
在服务端，实际上要解决的是当收到访问请求的时候，要知道这个请求从哪里来，要干什么，干完之后要回调什么东西给谁。
分析上图网址，发现我们传输了一个叫sys_key和一个叫action的参数，显然就是用来表明网站身份和目的的。sys_key所对应的信息存储在服务端中，服务端通过此参数可以知道来源网站名称、首页地址、回调地址等信息。
然后登录完成后，服务端自动将成功与否回调给预留的回调地址接口，如：
这就是服务端带参数跳转回此地址，我们传递了token和action两个动作。由token通过计算可以得出服务端的正确指令，从而客户端就知道该登录谁了。
难点提示：
此处需要解决的是安全性问题。即，如何确定服务端和客户端的通信是可靠的，而非恶意篡改。通常的做法是，使用一个只保存于数据库或程序文件中的密钥（各大开放平台通常称为app_secrect），双方传输指令时用此密钥进行可逆的加密，即可保障指令不可伪造。必须要强调的是，此密钥在任何情况下不可明文展示于不相关人士观看，一旦泄漏，需要立即重置。
在本系统中，我总体上是遵循以上思路，额外添加的一道保障是客户端接收到指令并解密后，还会与服务端进行一次验证通信，询问服务端是否发送了先前的指令。
客户端接收到服务端予以登录的指令后，可获取到相应的HMID、用户名，亦可根据权限不同接收电话号码、邮箱地址等高级信息。客户端网站需要首先确认该HMID是否在本站有注册过，如果没有的话需要执行注册流程，获取所需的额外信息。通常情况下，会有一个本站的ID，数据库中将其跟HMID绑定在一起即可。自此，用户中心不再参与后续流程。
注意：在执行初次登录流程时，服务端还会返回一个用户唯一的加密字符串，作为用户的唯一标识。客户端将其存储后，在以后的登录时，以此标识来识别用户（而非UID、用户名等明文信息），来确保服务端的指令合法性，此标识需对用户保密。
好处：
免除了重复注册的功夫。客户端也不再需要保存用户的密码信息，对用户来说也是安全性的提升。
总结：
本次编写的用户中心主要练习了较为复杂的程序逻辑、交互逻辑、函数复用等。为下一步的开发积累了经验。
该系统完成于2017年5月。