记录密码思路

通常记住密码之后的作用就是用户此次会话失效后，下次登录网站用户直接处于会话活动状态，不必输入用户名密码重新登录，一个很好的用户体验但是处理不好也会存在用户信息泄露的问题。

1、建一张表用来存储md5(username+md5(user_agent))，这个值也就是存储在客户端cookie中的。

表结构

CREATE TABLE `j_user_tokens` (  
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,  
`user_id` int(10) unsigned NOT NULL,  
`user_agent` varchar(40) NOT NULL,  --user_agent MD5值  
`token` varchar(40) DEFAULT NULL,  --md5(username+md5(user_agent))  `type` varchar(100) DEFAULT NULL,  
`created` int(10) unsigned DEFAULT NULL,  
`expires` int(10) unsigned NOT NULL, --过期时间，也就是记住密码多久  PRIMARY KEY (`id`),  
UNIQUE KEY `uniq_token` (`token`),  
KEY `fk_user_id` (`user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8

2、用户在某次选择”记住密码“登录时，在登录成功后将目前的信息作为一条新纪录都写入到j_user_tokens中，同时也要将token值写入到cookie名为autologin中。

3、用户关闭浏览器或此次session会话失效后；用户再次访问网站时，网站检测获取当前用户对象时首先在session中找寻，其次会进入记住密码机制查找；那么服务器获取到autologin值以及user_agent的值在j_user_tokens中检索匹配，如找到记录则检测是否已过期，过期则提示登录，未过期则获取user_id从而得到user对象，如未匹配到记录则直接提示登录。

这样的处理好处就是，避免将用户个人信息写入到不安全的cookie中去，不必采用username+password进行验证的方式。

注意：
这种存储方式避免了存储用户名和密码等关键信息到cookie，但如果获取了用户的cookie，并且使用和用户浏览器一样的userAgent来提交，会导致验证通过。

用户在登录界面选择了“记住密码”，那么登录成功后，关闭浏览器，后续在有效期内再次进入系统无需登录；如果用户在登录系统后，选择了退出系统，则后面再次进入系统需要登录；修改密码，也需要再次登录。

目前的这种设计仍然需要考虑cookie被劫持的情况