一天内完成用户管理，这个B2B2C电商小程序做了哪些事情？

本文所说的电商小程序为一个B2B2C在线蛋糕DIY平台，其主打“蛋糕在线定制”，并支持成品蛋糕的在线销售，以下简称该项目为BC。

作为一家初创公司，BC团队需要快速开发出产品原型以用来验证市场需求。而任何一个产品，为了跟踪数据，必须要有一套用户系统，这里面既包括了用户的登录、注册、第三方登录、忘记密码等琐碎功能，还包括了管理员对用户信息的管理和安全认证。如果先完成这些外围业务，必然会耽误核心业务实现。为了加快系统开发速度，减少一些不必要的开发时间，BC的创始人Steven选择了Authing云端身份认证来解决这一部分需求。

以下是他的分享：

选择

两个月前，我在V2EX上发现了Authing这个平台。那时，我正在构思BC项目，BC这个项目有两个核心业务，一个是B2B2C的电商平台，另外一个是在线DIY蛋糕。为了能够让我们的开发人员快速进入核心业务开发，我们计划使用Authing处理身份认证。

决定使用后我就联系上了Authing的创始人，他和我们进行了深入合作。比如BC客户端是在小程序上的，那时Authing还不支持小程序，因此我们绕道小程序，使用小程序新开放的web-view完成了Authing的接入。此外，Authing还协助我们完成了数据库的设计，我们本地数据库只存储了用户的authingId和小程序传过来的用户信息。

挑战

这一节我想多说一些技术接入上的细节，看不懂的可以直接跳到最后。

首先从业务说起，BC是一个B2B2C的平台，意味着我们至少需要三种用户身份：

买家（定制蛋糕、对蛋糕下单）

卖家（管理商品数据、接单、实行配送）

管理员（管理平台所有数据）

而Authing正好可以通过创建应用隔离用户数据，因此我们在Authing平台上创建了三个应用，并在程序中通过判断应用ID实现了BC系统中的权限隔离（应用的ID会附加在登录成功后的token中，可直接读取）。

自此我们解决了用户身份的问题，但是现在还不能立即接入业务，我们还需要设计数据库结构。在Authing的协助下，我们完成了三张用户表的数据库设计：

管理员表

卖家表

买家表

可见，我们的表结构都非常简单，完成这三张表，只花了10分钟。

在我们的开发团队写好了这三张表的增删查改和配置CORS后，我们开始正式接入Authing。

首先接入小程序。

前端使用了Authing提供的vue-demo中的代码，快速完成了一个基于web-view的认证网页。用户在第一次访问BC小程序时会先跳到这个网页进行认证（用户的微信信息通过postmessage的方式发送到认证网页上），认证网页再将用户信息发送给Authing进行认证，认证通过后即跳回小程序上，然后小程序存储Authing Token等信息完成认证（日后的每一次请求都需要发送Authing Token，然后后端验证该Token是否合法）。

整个过程花费了前端小哥2个小时的时间，当我们从测试小程序登录后发现Authing同步增加了用户数据并能看到统计后感到非常开心。

用户列表

用户详情

然后接入商家和管理员，我们要求商家只需使用微信扫码登录。

因为管理后台基于Web，所以直接使用Authing的JavaScript SDK即很快完成了开发。值得一说的是，在做微信扫码登录时，我们只写了客户端的登录存储代码，整个微信OAuth的开发过程极其简单。

最终的卖家登录界面

最终的管理员登录界面

投入生产环境

很难想象，我们在一天时间内就打通了用户流程，还拥有了一整套管理用户的GUI。第二天，我们的团队就投入到核心业务，整个过程非常顺利，两个月后我们完成了所有功能的开发、测试和运维，并将产品和Authing投入到了生产环境。

虽然Authing帮我们分担了很多工作，但Authing仍有很多功能待完善。比如应该增加用户管理的Hook功能，假如我在Authing的后台删除了一个用户，那么可以触发我的一个远程API，让我在本地数据库中也删除该用户的其它关联信息。同理，增加、修改都需要。但对于一个初创产品，Authing确实已经很好的满足了我们的需求。

我也看好Authing这种将一些基础功能基础设施化的云平台，如果追求效率，上云是个不错的选择。

中国并没经历工业化过程，从洋务运动到苏联的工业体系引进到加入WTO，所有这些技术变革都是上层引入带动，而不是像西方社会那样由资本家、发明家来推动社会生产关系变革。但是，在可预见的未来，随着金融、医疗和收入的提高，我看好中国社会未来的效率为主。

Authing.cn

云端身份认证服务

基于云的基础设施

解放部分社会生产力