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的其他模块不会擅自读取相关信息,二是相信不存在内存泄漏导致用户名密码泄露的问题