根据搜索查阅各位的资料经验，用户登录以后把密码存放在session里面是不可取的，这个我也认同这个观点。
假如目前网站登录成功以后会在session存放2个变量：userid和username,现在项目因为一些特殊的原因要求每一页面都验证一次用户密码，那么怎么进行对比好？查找到这个用户能获取到数据库里的密码，但是session里没有密码，怎么进行对比验证？
我想还是应该把密码信息存放在session里面，但怎么做才安全？描述的比较混乱，请见谅。
随机生成一个token，保存在session和数据库中，代替用密码进行对比验证。
token隔一段时间更新一次。
- 首先，数据库里面也不要存放密码，一般只存放hash后的密文；
- 其次session中的用户信息，一般都是用户登录成功后才写入，session失效时间即表示在指定时间内用户有效，不太理解为什么每个页面都要验证一次密码，这样用户也会填的很烦；
- 即使每个页面都要验证一次密码，也不要在session中放置密码，可以通过用户提交的密码hash密文与数据库中保留的hash密文进行比对；
- 强烈建议在前端对userid、页面的url和提交时间进行hash生成唯一的token，然后在服务端同样对session中userid和页面的url以及提交时间进行hash生成唯一的token，对这两个token进行比对验证；
不同的用户访问网站时都会分配不同的SESSIONID，关闭浏览器后，再次打开也会分配不同的SESSIONID。SESSION本来就是与用户相关的，通过来讲只要验证SESSION中的userid是否存在即可。存在SESSION['userid']就代表着这是一个经验验证的用户。因为只有通过验证后，才会把userid写入SESSION。
密码只在一些必须的操作时，要求再次输入进行。SESSION中不存，是不需要存，而不是每次都需要到数据库中去查询对比。
不得不说你这个需求挺奇葩的。
如果每个页面都需要验证用户密码那要SESSION干嘛？HTTP协议是无状态协议，无法维护事务与事务之间的状态（当同一个用户访问两个页面，会被认为没有关联）。
Cookies（客户端）和Session（服务端）主要就是为了解决这种事务之间的关联关系，也即“会话”。
一般来说当在一个页面（比如登陆页面）验证完用户的密码，都会把“已验证”的告诉Session，在别的页面判断“是否验证”就可以了。
所以你说的“因为一些特殊的原因要求每一页面都验证一次用户密码”，我不知道特殊的原因是什么？如果方便的话，你可以透露一下？或者改善一下你的需求？
// 登陆后，$_SESSION['user']['isLogin'] = 1;
$_SESSION = [
'user' => [
'userId' => 1003,
'userName' => 'BruceLee',
'isLogin' => 1 // 1为验证过密码，已登陆；0为未登陆
],
'others' => [...]
];
// 其他页面
if($_SESSION['user']['isLogin']){
// do something...
}else{
// go login...
}