Home > Backend Development > PHP Tutorial > 【判断用户登录】PHP这样判断流程是否正确?每次都查询数据库 存COOKIE

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

WBOY
Release: 2016-06-23 13:55:06
Original
1168 people have browsed it

我自己来做的PHP判断用户是否登录:

【流程】
1 先判断有没有cookie('uid') && cookie('uid') 如果没有跳出循环检测
2 如果有,连接数据库查询该uid对应的记录,如果没有改记录则跳出循环检测并且注销所有用户cookie
3 如果有,检测cookie('upwd')== md5($rs[pwd].cookie('salt')),如果不相等,提示密码发生修改需要重新登录
4 如果相等,检测cookie('email') == md5($rs[email]),如果不相等,提示邮箱发生更改,需要重新登录
5 如果相等 => 正确,该用户是当前登录用户。

但是!
【问题】
1 每次都要连接数据库,减少数据库查询是用户优化的关键,如果每次都去数据库查询,真的会影响性能。
2 如何优化才最好,这个登录判断流程是否有误。

【另外一种思路】
1 存放到SESSION,保存$uid,$uname,$lastactive(最后响应时间)到session中。
2 如果有session('uid') && session('uname') 检测time()-$lastactive > 3600 ,那么连接数据库查询(如上面的cookie判断),否则直接用(session存放位置php.ini默认配置的位置)

【问题】
1 如果存放到SESSION中,那么高并发的情况下,是否会受影响?


回复讨论(解决方案)

当采用第二种方案时你顾虑高并发的情况
那么采用第一种方案就可不考虑高并发的情况了吗?

在你的第一方案中,用户的口令和Email都放在cookie中,这些数据总是在网络中跑来跑去,你认为很安全吗?

数据库应该是广义的
虽然基于文件系统的关系型数据库(SQL)速度可能稍有逊色,但他们都提供有基于内存的内存表
何况数据库还有另一分支:基于内存的noSQL
所以数据库查询带来的额外开销是可以忽略不计的

判断用户是否登录的流程是:
如果 cookie('uid') 不存在 转要求登录处理
否则查询数据库,检查该 uid 上次登录地点是否与本次相同:
相同则确认
不同则发出提示,有条件转要求登录处理

当采用第二种方案时你顾虑高并发的情况
那么采用第一种方案就可不考虑高并发的情况了吗?

在你的第一方案中,用户的口令和Email都放在cookie中,这些数据总是在网络中跑来跑去,你认为很安全吗?

数据库应该是广义的
虽然基于文件系统的关系型数据库(SQL)速度可能稍有逊色,但他们都提供有基于内存的内存表
何况数据库还有另一分支:基于内存的noSQL
所以数据库查询带来的额外开销是可以忽略不计的

判断用户是否登录的流程是:
如果 cookie('uid') 不存在 转要求登录处理
否则查询数据库,检查该 uid 上次登录地点是否与本次相同:
相同则确认
不同则发出提示,有条件转要求登录处理



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

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

我的做法是这样的。
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页面

我的做法是这样的。
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页面




你的流程貌似没有查询过数据库,很节约,但是存在漏洞问题:
1 假如账号在11点正常登录,12点账号被盗,密码被修改。可他还可以继续使用账号,和那个盗号者一起共同使用
2 假设用户密码已经发生修改,可他没有退出重新登录却可以继续使用该账号
3 更关键的不可控,假设用户在11点登陆,12点管理员封禁其账号,可他却还是可以继续使用,除非他退出重新登录一次。



我的做法是这样的。
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页面




你的流程貌似没有查询过数据库,很节约,但是存在漏洞问题:
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分钟,检查一次


我的做法是这样的。
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页面




你的流程貌似没有查询过数据库,很节约,但是存在漏洞问题:
1 假如账号在11点正常登录,12点账号被盗,密码被修改。可他还可以继续使用账号,和那个盗号者一起共同使用
2 假设用户密码已经发生修改,可他没有退出重新登录却可以继续使用该账号
3 更关键的不可控,假设用户在11点登陆,12点管理员封禁其账号,可他却还是可以继续使用,除非他退出重新登录一次。




第1点 其实是 假如用户在网吧或其他区域登录忘了退出,之后别人使用那台上网设备就可以操作他账号的内容,即使用户回到家里修改密码也无济于事,除非那边退出重新登录(包括关机/重启/彻底关闭浏览器进程)。



我的做法是这样的。
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页面




你的流程貌似没有查询过数据库,很节约,但是存在漏洞问题:
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就过期了

更正一下。
当session过期,把cookies写入session时。在这个位置会连数据库判断用户是否被禁止登入。
session有自己的过期时间,所以,每次连数据库检查的时间间隔就是session的生命周期。

判断session是否存在->否->判断cookies是否存在->是->判断cookies解密是否成功->是-> 检查是否禁止登入->否->把cookies写入session->通过

判断session是否存在->否->判断cookies是否存在->是->判断cookies解密是否成功->是-> 检查是否禁止登入->是->清除用户cookies->跳转到通知页面




我的做法是这样的。
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页面




你的流程貌似没有查询过数据库,很节约,但是存在漏洞问题:
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的事件了。

更正一下。
当session过期,把cookies写入session时。在这个位置会连数据库判断用户是否被禁止登入。
session有自己的过期时间,所以,每次连数据库检查的时间间隔就是session的生命周期。

判断session是否存在->否->判断cookies是否存在->是->判断cookies解密是否成功->是-> 检查是否禁止登入->否->把cookies写入session->通过

判断session是否存在->否->判断cookies是否存在->是->判断cookies解密是否成功->是-> 检查是否禁止登入->是->清除用户cookies->跳转到通知页面



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




更正一下。
当session过期,把cookies写入session时。在这个位置会连数据库判断用户是否被禁止登入。
session有自己的过期时间,所以,每次连数据库检查的时间间隔就是session的生命周期。

判断session是否存在->否->判断cookies是否存在->是->判断cookies解密是否成功->是-> 检查是否禁止登入->否->把cookies写入session->通过

判断session是否存在->否->判断cookies是否存在->是->判断cookies解密是否成功->是-> 检查是否禁止登入->是->清除用户cookies->跳转到通知页面



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





session是会话进程,关闭会话消失很正常。
session其实也是cookie,只不过存活时间比较短,但是相较于cookie直接使用更安全,客户端只保存一个sessionid的cookie值,其他内容保存在服务器上,用户浏览时通过sessionid读取session的内容。

类似html5的 localStorage 和 sessionStorage



我的做法是这样的。
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页面




你的流程貌似没有查询过数据库,很节约,但是存在漏洞问题:
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设置了超时时间,到了时间 会失效吗?
Related labels:
source:php.cn
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template