问题背景
公司有两个产品，一个是运行在PC上的Web应用，一个是微信公众号H5应用。他们对于登录时限有不同的要求。
由于PC是公用资源，从安全角度看，要求session时间要短；
公众号页面在员工手机上运行，通过员工手机号登录。由于私人手机有密码、指纹等开机验证，因此可以认为，一旦登录过，这个手机就代表了员工本人，不需要对其频繁认证。
解决方案
- 延长session有效期（2周）
- session有效期短（1小时），针对手机端，启用remember me功能（2周）
对于方案1，延长session有效期来说，有一个比较致命的缺点是，其会大量消耗服务端存储资源。无论session信息是存储在内存，Redis，或者其他数据库中，由于session有效期延长，会导致数据被更长时间的保存。因为服务器session的方案，本质上是把应用状态数据保存到了服务器中，需要额外消耗资源。
remember me方案如果采用token的方式实现，即相当于把应用状态保存到了客户端。服务端不需要保存任何数据，可以大大降低服务器的压力。
从实际产品应用效果来看，2000个左右店员客户端登录，如果使用remember me方案，只需要5M bytes的内存；如果使用session，需要200M bytes左右。
当然，token方案存在一定的安全隐患，因为其实现是把用户名、密码通过一定方式hash成一个字符串，保存在客户端。不过考虑到用户都通过自己的手机登录这个场景，该方案的这个缺点并不明显。
Spring Security是如此计算token的：
下面都以Spring Security这个框架对Remember Me的实现来举例。其他框架可能在具体实现上有区别，但是总体思想上应该是一致的。
无论使用哪种认证方式，比如Basic, Digest, Form，在提交认证请求时，如果包含remember-me参数，Spring Security就会在response header中增加一个set-cookie项，其中包含remember-me token，默认有效期为2周。比如：
前面提到的remember-me参数，相关处理代码如下：
简单来说，当请求中包含remember-me参数，并且其值为true, on, yes, 1 其中之一时，会启动remember-me的相关处理。
注意：该参数必须通过form表单数据的方式提交。
其实，对于remember-me的token，Spring Security也支持持久化的token。其可以把token存储到数据库中，不过这样没有达到我们希望把应用状态保存在客户端的设想。
当session失效后，Spring Security会从remember-me cookie中尝试恢复。如果成功，就无需用户登录。具体是通过RememberMeAuthenticationFilter实现的：
这里有一个比较有意思的地方就是，Spring Security是如何从cookie中恢复用户登录的呢？毕竟cookie中只保存了用户名和过期时间，密码是被hash（MD5）过的（虽然MD5可以暴力破解，但是明显不划算）。
原来Spring Security是先根据username，从数据库中将用户信息加载出来，包括密码。然后再将用户名，密码，用户自定义的key放在一起参与hash计算。将计算结果与原来签名字符串进行比较。如果一致，就自动登录。
通过这个实现方式，我们可以反推出，只要用户修改了密码，或者服务器设置了新的key，都会导致remember-me失效。
