app后端用户登录api

app将用户名和密码发送到服务器，服务器验证用户名和密码都正确后，会在redis或memcached服务器中以用户id为键生成token字 符串，然后服务器把token字符串和用户id都返回给客户端（客户端通过token生成签名），例如token字符串"daf32da456hfdh" 和用户id"5"

　　假设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

服务器接收到这个url后，用userId获取token，再用相同的算法生成签名和sign参数对比，如果相等的话，就表示这个url是有效的,那就继续执行这个api调用，用上面的这个方法，就能避免token在api调用时泄露

　 　上面的方法还有一个问题，因为这个api请求＂test.com/user/info?userId=5& sign=C99DC0C22437AC275C08CE4A9708B25A＂上没有过期时间，假设别人拿到这个api的请求，就能反复调用了。改进方 法是在传递的参数中增加时间戳，当发现这个时间戳离现在的时间已经很久了，就判断这个url已经失效了。
　　但用时间戳怎么保证app的时间和服务器的时间同步？在app每次启动时和服务器同步时间，然后在app内建一个时钟，时间戳在这个app的内部时钟获取，防止用户修改了手机的时间导致时间不一致。

于是有了下面的改进方法：

　 　假设api请求为"test.com/user/info", 用token字符串"daf32da456hfdh"和时间戳生成md5签名后: md5("test.com/user/info?userId=5&token=daf32da456hfdh&timestamp=1425860757”)= C116161A6F430343B6CECF08562F1371，于是，api请求加上签名和用户标识后就是＂test.com/user /info?userId=5&timestamp=1425860757&sign= C116161A6F430343B6CECF08562F1371＂，服务器接收到这个api请求，如果发现收到这个url请求的时间和 time=1425860757相隔很久，就判断出这个url是被别人截取来反复调用了。如果时间合法，那就用上面的算法再判断sign是否一致，如果别 人修改了url上的时间戳也不用怕，因为签名会和服务器端的签名不相等