token原理

token原理
1.和session有很大关系哦。

jsp生成表单时，在表单中插入一个隐藏<input>字段，该字段就是保存在页面端的token字符串，同时把该字符串存入session中。等到用户提交表单时，会一并提交该隐藏的token字符串
。在服务器端，查看下是否在session中含有与该token字符串相等的字符串。如果有，那么表明是第一次提交该表单，然后删除存放于session端的token字符串，再做正常业务逻辑流程
；如果没有，那么表示该表单被重复提交，做非正常流程处理，可以警告提示也可以什么也不做。

2.token
你可以把他当做一个令牌，当第一次访问时设置一个令牌保存,一般我们保存在session中，当启动令牌时，那么就去检测令牌是否一致，然后销毁令牌或者重置令牌，这样第二次再用次
令牌访问时，就会不一致了，直接提示重复提交了

3.token是服务器给的，第一次登陆用户名和密码的时候，使用用户名去换取token，这样就类似于token：某人 一个键值对了。
4.一般token都有时长限制，token过期就重新登录
之后每次请求就直接使用token来请求数据 不需要每次都加用户名和密码去请求数据。

5,。两者在原理上都是通过session
token来实现的。当客户端请求页面时，服务器会生成一个随机数Token，并且将Token放置到session当中，然后将Token发给客户端（一般通过构造hidden表单）。下次客户端提交请求时
，Token会随着表单一起提交到服务器端。

6.究竟能起什么作用？验证身份？防止重复提交？可伪造吗？

6.最近正好打算写一个类似Token表单验证的东西
个人觉得如果单是表单验证的话似乎用Session比Cookie要好一些
但如果是跨子域名的话好像session传不过去

7.我们现在APP功能需要实现登陆一次，下次再打开应用的时候就不需要再去登陆了。
搜了下资料，常用的说是用token做比较好，具体怎么实现呢？大家有没有参考文档？
PS:我是服务端
前端是android和IOS
或者有其他办法保持登陆状态更好。
8.web端和服务器端进行http连接时，会使用cookie来进行状态的保存，让本来无状态的http变得“有状态”，你可以参考一下。
8.本地存储可以实现你的需求
9.APP每次登陆服务端将分配一个token给APP端，APP端所做的就是缓存token在本地。每次网络请求都将带上这个token，服务器每次收到网络请求验证token就行了。。。如果要让APP更
换token。验证不通过就行了 。
10.在很多app中，都需要用户的登录操作。登录，就需要用到用户名和密码。为了安全起见，暴露明文密码的次数越少越好。怎么能最大程度避免泄露用户的密码呢？在登录后，app后端
怎么去验证和维持用户的登录状态呢？在本文中，给出了一套用户登录的解决方案，以供大家参考。

11.在app后端，怎么避免每次验证用户身份都需要传输用户名和密码呢？

13.一个生活的模型就是：

　　假设服务器是个房间，里面有个房间管理员，房间上的门有把锁，这把锁有两种打开方式:

　　1. 输入了这把锁上注册的用户名和密码，就能打开

　　2. 用房间管理员提供的钥匙打开

　　a.当第一次使用用户名和密码打开了这把锁后，进入房间，找到房间管理员，让他提供一把钥匙。

　　b.那以后每次需要进入这个房间，就用这把钥匙就行了，不用担心旁边有人偷看到自己的用户名和密码.

　　c.决定有一段时间不进入这个房间，又怕钥匙被偷，就进入房间里，把钥匙还给管理员，让管理员把钥匙毁灭

　　a就是登录的操作，ｂ就是验证身份的操作，ｃ就是退出登录的操作.

理论版的描述如下：

　　(1) 服务器接收到app发送的用户名和密码后，验证用户名和密码是否正确。

　　如果错误则返回错误信息。

　　如果验证正确，生成一个随机的不重复的token字符串（例如"daf32da456hfdh"），在redis或memcache中维护一个映视表，建立token字符串和用户信息的对应关系表，例如，把token字符串"daf32da456hfdh"和用户id"5"对应起来。

　　(2) 服务器把token字符串返回给app，app把这个token字符串保存起来，作为登录的验证。

　　(3) 当需要验证用户身份的操作时，必须要把token字符串传给服务器验证身份。

　　例如，api "test.com/user/update"是更新用户的信息，必须要验证用户的身份.当调用api "test.com/user/update"时，把token字符串"daf32da456hfdh"放在url上，变成"test.com/user/update?token=daf32da456hfdh" .

　　当服务器接收到这个api请求，知道要验证用户身份的，于是，就把参数中token的值"daf32da456hfdh"取出来，在(1)中建立的token字符串和用户信息的对应关系表查找，如果发现没这个token值的，则返回验证失败的信息。如果发现有这个token值，则获取这个用户的信息,进行相关的更新操作。

(4) 当用户退出登录时，需要通过调用api，让服务器把这个用户对于的token字符串删除.

　　例如，api "test.com/user/logout"是退出登录的api,也要验证用户身份， 则调用"test.com/user/logout?token=daf32da456hfdh" 。当服务器接到退出登录的api请求时，在(1)中建立的token字符串和用户信息的对应关系表查找token字符串，把token和用户信息都删除即可。

　　注意：这个方案并不是十分安全，这个身份验证是依赖于token字符串。如果用户泄漏了自己的url, 那很大程度上token也被别人泄漏了，就相当于钥匙被人复制了一份。在下篇的通讯安全中，会描述一个防止token在通讯中泄漏的方案。

20.在前一篇文章<15.app后端怎么设计用户登录方案>中，服务器中验证用户名和密码都正确后,生成一个随机的不重复的token字符串（例如"daf32da456hfdh"），在redis或memcache中维护一个映视表，建立token字符串和用户信息的对应关系表，例如，把token字符串"daf32da456hfdh"和用户id"5"对应起来，服务器把token字符串返回给app用作身份验证。

　　这个身份验证是依赖于token字符串。如果用户泄露了自己的url, 那很大程度上token也被别人泄漏了。

　　怎么防止token被泄露？不让token在网络上传输就行。

app和后端的通讯过程中，api请求有可能被别人截取或不小心泄露。那么，怎么保证api请求的安全呢？在这篇文章中，介绍一种常见的保证api请求安全的做法--url签名。

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&timestamp=1425860757”)= C116161A6F430343B6CECF08562F1371

　　于是，api请求加上签名和用户标识后就是　＂test.com/user/info?userId=5&timestamp=1425860757&sign= C116161A6F430343B6CECF08562F1371＂

　　(2)服务器接收到这个api请求，如果发现收到这个url请求的时间和time=1425860757相隔很久，就判断出这个url是被别人截取来反复调用了。如果时间合法，那就用(1)的算法再判断sign是否一致

2. url签名的不足之处

　　url签名有两个缺点：

　　1.当用户第一次登录后token是明文返回，有被截取的风险

　　2. url签名只能保护token值却没法保护其他敏感数据,例如，当用户更新自己的个人信息时，所有的信息在传输过程中应该是被加密的

　　怎么解决这两个问题？使用下篇介绍的对称加密的算法就可以了。