一、账号绑定架构设计

• 　　用户点击绑定某个平台的账号，则向openid获取api发起请求(此域名是在buyer下，也是就是有权限的验证的)
• 　　openid获取时的callback是跳向passport域名的(因为第三方平台的限制，callback只有是同一个域名)
• 　　拿到openid后，生成一个uuid并将type和openid一起写入reids
• 　　然后转向跳转至指定的绑定成功页，同时向cookie中写入uuid
• 　　在这个页面，前端会发出绑定请求(携带uuid参数和token)，此时请求的域名是buyer的，会校验token并找到当前用户，然后进行绑定。

二、账号绑定API

1、PC端跳转API

　　路径

　　参数

　　处理逻辑

• 　　拼接参数
• 　　redirect至第三方平台

2、WAP跳转API

　　路径

　　参数

　　处理逻辑

• 　　拼接参数
• 　　redirect至第三方平台

3、callbackAPI

　　路径(注意此处用passport的域名，此处的api应在passport中)

　　参数

　　逻辑处理

• 　　和第三方平台交互获取openid将uuid和openid、access_token、type参数进行绑定：
• 　　向redis以OPENID_{UUID}的key写Auth2Token对象：
• 
• 　　有效期为5分钟
• 　　写入成功后，跳转至/account-binder，并将uuid写入cookie:
• 　　名称为uuid，path为主域名，有效期为5分钟

4、绑定openidAPI

　　路径

　　参数

　　处理逻辑

• 　　由redis中取出对应的type和openid
• 　　由usercontext中拿到buyer
• 　　将两者在数据库中建立关联

5、取消绑定API

　　路径

　　参数

　　处理逻辑

• 　　由usercontext中拿到buyer
• 　　删除type类型的openid
• 　　一个月内只，同一个openid允许解绑一次

6、获取绑定列表API

　　路径

　　参数

　　无

　　处理逻辑

• 　　读取出此用户各个平台的绑定情况列表，要含有类型、是否已经绑定字段，不用分页

　　以上就是所有关于账号绑定架构设计与绑定API规划的内容了，想知道更多关于技术方面的信息，可以持续关注易族智汇javashop。

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。