1. url签名详解
在前一篇文章<15.app后端怎么设计用户登录方案>中，服务器中验证用户名和密码都正确后,生成一个随机的不重复的token字符串（例如"daf32da456hfdh"），在redis或memcache中维护一个映视表，建立token字符串和用户信息的对应关系表，例如，把token字符串"daf32da456hfdh"和用户id"5"对应起来，服务器把token字符串返回给app用作身份验证。
这个身份验证是依赖于token字符串。如果用户泄露了自己的url, 那很大程度上token也被别人泄漏了。
怎么防止token被泄露？不让token在网络上传输就行。
注意，这个url签名的方法是和前面＜15.app后端怎么设计用户登录方案＞紧密联系在一起的，没看过前面一篇文章请先看。
(1) 服务器中验证用户名和密码都正确后，把token字符串和用户id都返回给客户端，例如token字符串"daf32da456hfdh"和用户id"5"。
(2)假设api请求为"test.com/user/info", 通过token字符串"daf32da456hfdh"生成md5签名后: md5("test.com/user/info&token=daf32da456hfdh”)= C99DC0C22437AC275C08CE4A9708B25A
于是，api请求加上签名和用户标识后就是 ＂test.com/user/info?userId=5&sign= C99DC0C22437AC275C08CE4A9708B25A＂
(3)服务器接收到这个url后，用(2)的算法生成签名和sign参数对比，如果发现相等的话，就表示这个url是有有效,那就继续执行这个api调用。
用上面的这个方法，就能避免token在api调用时泄露。
上面的方法还有一个问题，因为这个api请求＂test.com/user/info?userId=5&sign= C99DC0C22437AC275C08CE4A9708B25A＂上没有过期时间，假设别人拿到这个api的请求，就能反复调用了。
改进方法是在传递的参数中增加时间戳，当发现这个时间戳离现在的时间已经很久了，就判断这个url已经失效了。
但用时间戳怎么保证app的时间和服务器的时间同步？在app每次启动时和服务器同步时间，然后在app内建一个时钟，时间戳在这个app的内部时钟获取，防止用户修改了手机的时间导致时间不一致。
于是有了下面的改进方法：
(1)假设api请求为"test.com/user/info", 用token字符串"daf32da456hfdh"和时间戳生成md5签名后: md5("test.com/user/info?userId=5&token=daf32da456hfdh×tamp=1425860757”)= C116161A6F430343B6CECF08562F1371
于是，api请求加上签名和用户标识后就是 ＂test.com/user/info?userId=5×tamp=1425860757&sign= C116161A6F430343B6CECF08562F1371＂
(2)服务器接收到这个api请求，如果发现收到这个url请求的时间和time=1425860757相隔很久，就判断出这个url是被别人截取来反复调用了。如果时间合法，那就用(1)的算法再判断sign是否一致
2. url签名的不足之处
url签名有两个缺点：
1.当用户第一次登录后token是明文返回，有被截取的风险
2. url签名只能保护token值却没法保护其他敏感数据,例如，当用户更新自己的个人信息时，所有的信息在传输过程中应该是被加密的
怎么解决这两个问题？使用下篇介绍的对称加密的算法就可以了。
---------------------------------------------------------------------------------------------------------------------------
打开链接 app后端系列文章总目录 总目录 ，能查看本人发表过的所有原创“app后端”文章。
【作者】曾健生
【QQ】190678908
【app后端qq群】254659220
【微信公众号】 appbackend
【新浪微博】 @newjueqi
【博客】http://blog.csdn.net/newjueqi
版权声明：本文为博主原创文章，未经博主允许不得转载。