why token?

最近的一个项目里,客户端与服务器做业务逻辑请求时,都会发生UserID 来识别该用户,并进行相应业务处理。为了防止信息被盗取,加了SSL,后来突然想到一个问题,如果客户端的代码被反编译破解之后,其调用的服务器接口都会暴露出来,包括一些支付的敏感接口。那么这个时候,陌生人就可以直接请求HTTPS接口,因为UserID是相对有规则的,而且是没用防备的,而且可以直接绕开登陆流程。
因此,参考类似于OAUTH协议,应该是首先登陆完成,用户分配一串token,后面的接口都以token为准,这样陌生人直接请求接口也会因为没有合法的token而被拒。token相对于userID最大的特点就是无序,位数长,有失效时间,因此在敏感业务必须用上此机制。
(有人问这个token和一般App Sever的sessionID有什么区别? 其实也没有什么区别(我没有用sessionID- -#,其实是当初大意疏漏了,用了也没这个事了。。。),就是维护一个彼此之间的会话不被第三方陌生人知道。token相比于sessionID 应用环境应该更大一点,系统跨度更广,因为将用户登录授权单独做成了一个模块。

总结:用户验证机制还是要做成一个流程,绕前执行过滤,Mark,否则以后肯定会有坑。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>