Vcenter 踩坑记

“过度设计等于没有设计”

前言

Vcenter的后台框架经过一段时间的填充已经大体有模有样了，后台专门设置一个APIController，调用各个不同的模块来提供服务。但是在编码之余却又发现了一个坑点。

过度设计

在Vcenter 的设计之初，API部分便有着两方面考虑，一方面是正经的网页后台，另一方面是客户端后台，提供给APP等客户端使用，虽然同样是通过HTTP协议通信，但是可以切换认证方式为token认证。

这样一来，问题就出现了，为了使用token认证，就是说为了保证HTTP请求的最小化，在使用token认证的时候，其实是不需要使用cookies的，也就是说，每一个请求都是通过token来充当cookies的功效，但是仅仅用作认证，那么我们在使用token认证的时候是无法维持HTTP会话的状态的。

很多时候，HTTP会话是需要维持一个状态的，简单来说就是SESSION，在普通的网页后台上，通过cookies中标识SESSION_ID，由后台使用SESSION来保存数据已经是一个常用做法，但是为了兼容Token验证模式，那么一个API模块在调用的时候便会陷入这样一种问题：

  • 如果我需要使用SESSION，我需要先判断当前的登录模式
  • 碰到在一个SESSION才能解决的场合，无法使用SESSION

这个实际上是非常不合适的，为了兼容这种写法，特地还诞生了很多奇奇怪怪的做法，比如说，对模块的可访问性校验时，要对Token和SESSION两种方式进行区分，又比如说，需要规定业务模块不得单独引用SESSION（这一个规定简直不可理喻）

解决问题

经过了长久的思想斗争，终于发现是自己犯了过度设计的毛病，在系统搭建之初就对未来可能不存在的功能进行了预先设计，而且还很明显出现了偏差，当即拍板决定，Token部分全面砍掉——砍掉是不可能砍掉的，Revert Git之前还是需要三省吾身，这个功能不是无可救药，但是具体的修改方式，可以从长计议。

行文至此时，已有一个大概想法，于是顺便记录下来。

  1. 将Token引入框架判定的问题必须要改，这一块的逻辑必须重构，不能让两种用途的代码鱼目混珠
  2. API 模块还是需要SESSION的，那么Controller不妨就不要去管Token的实现，实际上也完全没有必要，因为这并不属于业务逻辑
  3. 最重要的是，SESSION与Token实际上是可以兼容的，比如说setCookie在客户端进行特殊处理，取出SESSION_ID作为请求头，而SESSION插件也另外检查该请求头来作为标识符来源，这样也是可行的，只是与token这种长期性质的令牌性质有点冲突，但是影响不大

总计

本想写后记的，但是代码均还未修改，待到重构以后再细细记录吧，这次的过度设计事件也给我提了个醒，不徒手撸一个轮子永远不知道前方有多少的坑再等着你。

为了Vcenter能够成为一个足够健壮的框架，开发手册与备忘也已记录了很多，最近又搞定了几处的优化和兼容问题，想来面世已指日可待了。开心呀开心 。:)

PS

不知是否会有人看到这边。顺手记录另一个问题

在开发的时候，考虑了很久，Session当中到底应该存什么，有人直接存登录成功的用户信息，有人存用户名和密码。

思来想去，感觉还是存用户名密码稳妥一点，经常看到有些网站，改了密码以后还可以凭借cookies继续使用之前的帐户，要等待cookies过期才可。

Vcenter为了保持长在线，Session策略为自动刷新有效期（默认配置，可以修改）

如果存用户名密码的话，这样哪怕被盗取了Cookies，亦可以通过修改用户名密码的方式强制使SESSION失效，想来是最稳妥的方案了。

当然，这后面是对Vcenter的信心……一是要规定Vcenter的其他模块不会擅自读取相关信息，二是相信不存在内存泄漏导致用户名密码泄露的问题