使用ETag进行session的降级

回顾

在web后台开发中我们经常需要存储一些变量到session中进行暂存，最为特殊的就是“购物车”，由于http的无状态特性，因此我们需要在客户端打上一个标记，唯一的标示客户端并和服务端session一一对应，因此就有了通过cookie和url进行存储或传递这个标示－－sessionID。

sessionID是一个长的字符串，它往往默认通过cookie来保存，这个session并不持久化到硬盘而是暂存到内存中，每次请求时都会在head中带上这个包含sessionID的cookie，服务端可以根据该id标示出客户端，从而访问服务器的一片内存区；另一种通过url方式传递sessionID，当cookie在客户端被禁用时，服务端会将生成的sessionID加入到url，以此完成sessionID的传输，又称url回写。但是url回写会有明显的安全漏洞，当该网站被xss注入时，攻击者就可以通过窃取的sessionID访问服务端的隐私数据。

惊喜

无意中，在snoopyXDY的文章中看到了用ETag进行兼容，大喜，并感慨于该方法的奇妙。（之前遇到过ETag在服务器集群中同步的问题，原因是在服务端生成ETag的方式不妥，最终解决方案就是针对请求文件的内容进行hash并base64编码，这样在服务端同步的前提下，请求任意服务器都会返回相同的ETag）在此处实现中，则是异步请求一个js文件，该文件会根据客户端的相关头部设置或获取session，并且在服务端触发客户端的相关事件，完成数据的传递。

github地址：https://github.com/royalrover/ETag-Session

揭秘

首先，我们访问登陆页面login.html,在页面底部的script中，异步加载一个名称为‘eTag.js’的文件，这个文件并不是静态的，而是由服务端根据客户端传递的参数进行相应处理：如果客户端的request头部有‘if-none-match’字段，则会在内存中查看是否有该字段对应的value（服务端用hash进行存储各个客户的的session），并将该value值序列化，同时触发客户端的‘etag-ready’事件，并将序列化的value作为值传入。

在这里的实现中，有可能会存在浏览器对动态文件‘eTag.js’的缓存，为了避免‘eTag.js’的准确和实时，因此需要设置‘cache-control’头部。

router.get('/_eTag_.js',function * (next){
var ctx = this;
var etag = ctx.header['if-none-match'];
var cache;

if(!etag) {
etag = new Date().getTime() + '__etag';
}
//    console.log(session)
if(session[etag]) {
cache = session[etag];
}else {
cache = {
etag: etag
};
}
cache = JSON.stringify(cache);
ctx.set('ETag',etag);
ctx.set('cache-control','no-cache');
ctx.set('content-type','application/javascript');
//    ctx.body = 'window._session = '+ cache + ';';
ctx.body = 'd.do("etag-ready",'+ cache +')';
//    console.log('cache: '+cache)
yield *next;
})

在处理post请求时，node并不会解析body，因此需要我们自己来搞定，可以通过模块，也可以简单的通过订阅事件，在这里我是简单的用node原生的request对象进行侦听。

为了避免js阻塞渲染，采用异步加载的方式获取，但这也会造成从服务端获取的数据不能及时被客户端处理和渲染，为了解决这个问题，此处采用了重量级应用必备的解决方案－Bigpipe，有服务端出发客户端订阅的事件，一旦服务端去到session数据，则触发'etag-ready'事件，并在客户端进行逻辑处理和渲染。

客户端的逻辑如下：

function $(n){
return document.querySelectorAll(n);
}

function asyncLoad(src) {
var s = document.createElement('script');
s.src = src;
s.async = true;
document.body.appendChild(s);
}

function DO(){
this.cbs = [];
}
DO.prototype.on = function(k,cb){
if(!this.cbs[k]) {
this.cbs[k] = [];
}
this.cbs[k].push(cb);
};
DO.prototype.do = function(k,data){
if(!this.cbs[k])
return;
var cbs = this.cbs[k],len = cbs.length;
for(var i=0;i<len;i++){
cbs[i].call(this,data);
}
};

asyncLoad('/_eTag_.js');
var d = new DO();
d.on('etag-ready',function(_session){
console.log('etag-ready...');
console.log(_session);
if(_session && _session.etag && !_session.usrname) {
$('[name=etag]')[0].value = _session.etag;
}else {
$('[name=usrname]')[0].value = _session.usrname;
$('[name=pwd]')[0].value = _session.pwd;
$('[name=etag]')[0].value = _session.etag;
}
})

总结

使用ETag方式来hack兼容性是非常棒的，几乎所有的服务器都实现了这个机制（HTTP1.1规范），因此兼容性不是问题。由于使用ETag加载的文件的元数据都保存在浏览器的缓存中，因此安全性是没法与存储在内存中的cookie方式相比的，而且如果清空浏览器缓存，那么客户端则丢失sessionID，没法在使用session。因此这种方式也仅仅作为cookie被禁用的一种候补方案，不推荐大规模使用。