最近涉及到一个数据迁移的业务场景,之前对AT有一定的了解,没这么深刻,这次算是比较深的理解。
摘自: bbs 作者:chendejia2012
其实token就相当于sessionId,为什么app喜欢用token,而不用sessionId呢?
app说他们保管cookie不方便,不好维护cookie,因为cookie是浏览器的东西,app天生不支持cookie。我觉得很奇怪,浏览器也会出现关闭cookie的时候,这时,服务器会重写url,将sessionId放到url后面,如果app不打算用cookie,那么与浏览器关闭cookie无异,服务器将sessionId放到url后,app完全可以把sessionId拿出来,缓存到app数据库或者内存中,下次访问服务器就带上sessionId。
服务器默认的sessionId名称叫JSESSIONID,app说他们需要token,那么就把JSESSIONID换一个名称,就叫token,那么服务器和重写url返回sessionId一样,就把token放到url后面就可以了。实际token和JSESSIONID的值是一样的,换汤不换药,然后APP开发会觉得很高兴,他们终于拿到想要的token了。然而对api开发来说,感觉这其实多此一举。
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
那么到底是不是多此一举,token是怎么来的呢?为什么会有token这个说法和用法?
毕竟我相信“存在即合理”
实际如果app后面对应的服务器如果是分布式系统,就需要token了。
因为app需要到登录服务器上登录,然后到应用服务器去获取数据,这里涉及到不同的服务器,那么不同服务器对应到该app客户端的sessionId肯定不一样,app不像浏览器那么强大,管理不同域下的sessionId都很方便,这时app肯定希望有一个统一的sessionId,那就是token,方便访问不同的服务器。
还有一个理由是,应用服务器需要校验当前app是否登录,于是要到登录服务器上去询问,询问时总要带个app的凭证吧,于是需要一个token,这个token是登录服务器给app的,应用服务器拿着这个token去询问登录服务器,登录服务器校验该token后,就会告知应用服务器当前app是否合法(在我这里登录过),然后应用服务器才能放心的把数据返回给app。
大家可以参考单点登录服务器与应用服务器,与客户端的交互,便可知道token的用法了。实际如果应用服务器同时带登录功能,那么完全可以不必搞个token出来,就沿用sessionId就可以了。如果app非要token,那么可以修改server.xml,把默认JSESSIONID改成token。
经常会看到第三方服务接口,如新浪微博,都需要带上一个access_token,实际新浪微博就相当于一个第三方登录系统,而且心流浪微博后面会有多个分布式系统,系统与系统之间交互肯定需要token,那么新浪微博就会要求客户端带上access_token,而这个access_token是可以通过新浪微博接口获取的,每获取一次,access_token会改变,看来这个access_token就像一个sessionId,可以重置。
至于说经常会有服务器开发和app开发争论token和sessionId谁优谁劣完全没有意思,具体问题具体分析,该用什么就用什么。就好像争论java好还是c好,还是PHP好一样,不同的东西有不同的业务场景。
还是那句话 “ 存在即合理 ”...