前言
现在项目有这样的改造需求，在原来用户名+密码的登录方式，添加上通过ukey的登录方式。需要前端Vue、jwt交互、后端权限验证、数据类型转换等知识。对我而言综合性很强，表面看虽然只是登录，但解决问题的过程碰到很多问题。
业务流程
先把大体的业务流程梳理清楚
前端：浏览器通过js调用厂家提供的方法，可以实现读取ukey序列号，调用前端提供的签名算法。还可以导出保存在ukey的证书。证书由负责密码的同事生成。
后端：调用调用签名验签服务器生成随机数，验证证书，签名值。
前端页面
由于我前端基础比较差，解决前端的问题也比较吃力。很多相关工作要煜总（全栈架构师）帮助，首先在原来登录页下面，加入一个切换按钮，点击后切换为ukey登录方式。然后要写js的逻辑，比如请求后端的代码，渲染返回数据等等。
单元测试
我是用厂家已经提供好一部分前端js示例代码，先把从后端获得随机数改成固定的字符，证书和签名值生成后打印在控制台。在后端单元测试直接用上面的数据调用上面说到的数据，验证签名。这一步很关键，如果这一步通过，那么后面出现什么问题，排查范围就能缩小了。这块出现的bug就是在调用验签方法的传入参数，参数是byte[]类型，在这个类型的数据外包一个这个转换：Base64.decode()。当时因为解决这个bug耽误了不少时间。
还有公司有一个系统（算法验证平台）可以对签名验签进行验证，可以辅助测试。如果这个平台对测试的参数通过，那就是业务代码哪有问题。
代码实现
单元测试通过的话，相当于又前进了一步，接下来就是写具体代码了。前端主要是煜总（全栈架构师）写，当时出现了一个问题，随机数设置成固定值的话，系统验签是没问题的，但代码改成从签名验签获取，总验证不成功。还是返回上部进行单元测试，多分析，发现前端数据格式转的有点问题。
总结
刚开始做这个功能的很迷茫，毕竟自己很多知识掌握的不扎实，也花了一些时间，差点奔溃，但还好后来坚持下去了。
