【判断用户登录】PHP这样判断流程是否正确？每次都查询数据库 存COOKIE

Question

用户登录sessionCOOKIE安全

Answer 1

当采用第二种方案时你顾虑高并发的情况
那么采用第一种方案就可不考虑高并发的情况了吗？在你的第一方案中，用户的口令和Email都放在cookie中，这些数据总是在网络中跑来跑去，你认为很安全吗？数据库应该是广义的
虽然基于文件系统的关系型数据库（SQL）速度可能稍有逊色，但他们都提供有基于内存的内存表
何况数据库还有另一分支：基于内存的noSQL
所以数据库查询带来的额外开销是可以忽略不计的判断用户是否登录的流程是：
如果 cookie('uid') 不存在 转要求登录处理
否则查询数据库，检查该 uid 上次登录地点是否与本次相同：
相同则确认
不同则发出提示，有条件转要求登录处理

Answer 2

那每次都要查询MYSQL数据库了。根据登录地址，一般来说是IP了。

Answer 3

检查用户来源，是为了防止 CSRF攻击
一般只在用写动作的页面进行

Answer 4

我的做法是这样的。
1.用户login，连接数据库判断是否成功，如成功后把用户id，用户name等需要用到判断的信息，写入session和cookies，cookies设置一个时间（例如1天~2周，这个登入时给用户自己选择），另外，我是把存入cookies的数据做一个json_encode，然后加密处理。
例如 {"uid":1,"username":"fdipzone"} 加密成可逆的字符串。2.当用户访问时，会有以下几种情况
1.判断session是否存在->是->通过
2.判断session是否存在->否->判断cookies是否存在->是->判断cookies解密是否成功->是->把cookies写入session->通过
3.判断session是否存在->否->判断cookies是否存在->是->判断cookies解密是否成功->否->跳转到login页面
4.判断session是否存在->否->判断cookies是否存在->否->跳转到login页面

Answer 5

你的流程貌似没有查询过数据库，很节约，但是存在漏洞问题：
1 假如账号在11点正常登录，12点账号被盗，密码被修改。可他还可以继续使用账号，和那个盗号者一起共同使用
2 假设用户密码已经发生修改，可他没有退出重新登录却可以继续使用该账号
3 更关键的不可控，假设用户在11点登陆，12点管理员封禁其账号，可他却还是可以继续使用，除非他退出重新登录一次。
我判断closeuser的部分在login之后进行。因为如果前面的步骤都不成功，就不需要调用closeuser判断了。对了，有个位置漏说了，当session过期，然后把cookies写入session时。我会把这次操作的时间记录入db，作为用户的最后在线时间的。当判断上一次的最后在线时间比现在的超过10分钟，我会check一次closeuser的表，判断是否被屏蔽。如果被屏蔽，就跳到对应的信息提示页面。就是每10分钟会检查一次db吧。
判断session是否存在->否->判断cookies是否存在->是->判断cookies解密是否成功->是->把cookies写入session->通过然后，每10分钟，检查一次

Answer 6

你的流程貌似没有查询过数据库，很节约，但是存在漏洞问题：
1 假如账号在11点正常登录，12点账号被盗，密码被修改。可他还可以继续使用账号，和那个盗号者一起共同使用
2 假设用户密码已经发生修改，可他没有退出重新登录却可以继续使用该账号
3 更关键的不可控，假设用户在11点登陆，12点管理员封禁其账号，可他却还是可以继续使用，除非他退出重新登录一次。
我判断closeuser的部分在login之后进行。因为如果前面的步骤都不成功，就不需要调用closeuser判断了。对了，有个位置漏说了，当session过期，然后把cookies写入session时。我会把这次操作的时间记录入db，作为用户的最后在线时间的。当判断上一次的最后在线时间比现在的超过10分钟，我会check一次closeuser的表，判断是否被屏蔽。如果被屏蔽，就跳到对应的信息提示页面。就是每10分钟会检查一次db吧。
判断session是否存在->否->判断cookies是否存在->是->判断cookies解密是否成功->是->把cookies写入session->通过然后，每10分钟，检查一次如果用session存放信息，当关闭浏览器（包括强制关闭浏览器进程），那么是不是session就过期了

Answer 7

更正一下。
当session过期，把cookies写入session时。在这个位置会连数据库判断用户是否被禁止登入。
session有自己的过期时间，所以，每次连数据库检查的时间间隔就是session的生命周期。判断session是否存在->否->判断cookies是否存在->是->判断cookies解密是否成功->是->检查是否禁止登入->否->把cookies写入session->通过判断session是否存在->否->判断cookies是否存在->是->判断cookies解密是否成功->是->检查是否禁止登入->是->清除用户cookies->跳转到通知页面

Answer 8

你的流程貌似没有查询过数据库，很节约，但是存在漏洞问题：
1 假如账号在11点正常登录，12点账号被盗，密码被修改。可他还可以继续使用账号，和那个盗号者一起共同使用
2 假设用户密码已经发生修改，可他没有退出重新登录却可以继续使用该账号
3 更关键的不可控，假设用户在11点登陆，12点管理员封禁其账号，可他却还是可以继续使用，除非他退出重新登录一次。
我判断closeuser的部分在login之后进行。因为如果前面的步骤都不成功，就不需要调用closeuser判断了。对了，有个位置漏说了，当session过期，然后把cookies写入session时。我会把这次操作的时间记录入db，作为用户的最后在线时间的。当判断上一次的最后在线时间比现在的超过10分钟，我会check一次closeuser的表，判断是否被屏蔽。如果被屏蔽，就跳到对应的信息提示页面。就是每10分钟会检查一次db吧。
判断session是否存在->否->判断cookies是否存在->是->判断cookies解密是否成功->是->把cookies写入session->通过然后，每10分钟，检查一次如果用session存放信息，当关闭浏览器（包括强制关闭浏览器进程），那么是不是session就过期了是的，那么就会执行判断cookies的事件了。

Answer 9

如果是这样，貌似不用再SESSION了吧。
不过关闭浏览器就session过期真的不可思议啊

Answer 10

如果是这样，貌似不用再SESSION了吧。
不过关闭浏览器就session过期真的不可思议啊session是会话进程，关闭会话消失很正常。
session其实也是cookie，只不过存活时间比较短，但是相较于cookie直接使用更安全，客户端只保存一个sessionid的cookie值，其他内容保存在服务器上，用户浏览时通过sessionid读取session的内容。类似html5的 localStorage 和 sessionStorage

Answer 11

你的流程貌似没有查询过数据库，很节约，但是存在漏洞问题：
1 假如账号在11点正常登录，12点账号被盗，密码被修改。可他还可以继续使用账号，和那个盗号者一起共同使用
2 假设用户密码已经发生修改，可他没有退出重新登录却可以继续使用该账号
3 更关键的不可控，假设用户在11点登陆，12点管理员封禁其账号，可他却还是可以继续使用，除非他退出重新登录一次。
我判断closeuser的部分在login之后进行。因为如果前面的步骤都不成功，就不需要调用closeuser判断了。对了，有个位置漏说了，当session过期，然后把cookies写入session时。我会把这次操作的时间记录入db，作为用户的最后在线时间的。当判断上一次的最后在线时间比现在的超过10分钟，我会check一次closeuser的表，判断是否被屏蔽。如果被屏蔽，就跳到对应的信息提示页面。就是每10分钟会检查一次db吧。
判断session是否存在->否->判断cookies是否存在->是->判断cookies解密是否成功->是->把cookies写入session->通过然后，每10分钟，检查一次如果用户一直在操作页面 那SESSION设置了超时时间，到了时间 会失效吗？