搜索
首页后端开发php教程【判断用户登录】PHP这样判断流程是否正确?每次都查询数据库 存COOKIE

我自己来做的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设置了超时时间,到了时间 会失效吗?
声明
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn
继续使用PHP:耐力的原因继续使用PHP:耐力的原因Apr 19, 2025 am 12:23 AM

PHP仍然流行的原因是其易用性、灵活性和强大的生态系统。1)易用性和简单语法使其成为初学者的首选。2)与web开发紧密结合,处理HTTP请求和数据库交互出色。3)庞大的生态系统提供了丰富的工具和库。4)活跃的社区和开源性质使其适应新需求和技术趋势。

PHP和Python:探索他们的相似性和差异PHP和Python:探索他们的相似性和差异Apr 19, 2025 am 12:21 AM

PHP和Python都是高层次的编程语言,广泛应用于Web开发、数据处理和自动化任务。1.PHP常用于构建动态网站和内容管理系统,而Python常用于构建Web框架和数据科学。2.PHP使用echo输出内容,Python使用print。3.两者都支持面向对象编程,但语法和关键字不同。4.PHP支持弱类型转换,Python则更严格。5.PHP性能优化包括使用OPcache和异步编程,Python则使用cProfile和异步编程。

PHP和Python:解释了不同的范例PHP和Python:解释了不同的范例Apr 18, 2025 am 12:26 AM

PHP主要是过程式编程,但也支持面向对象编程(OOP);Python支持多种范式,包括OOP、函数式和过程式编程。PHP适合web开发,Python适用于多种应用,如数据分析和机器学习。

PHP和Python:深入了解他们的历史PHP和Python:深入了解他们的历史Apr 18, 2025 am 12:25 AM

PHP起源于1994年,由RasmusLerdorf开发,最初用于跟踪网站访问者,逐渐演变为服务器端脚本语言,广泛应用于网页开发。Python由GuidovanRossum于1980年代末开发,1991年首次发布,强调代码可读性和简洁性,适用于科学计算、数据分析等领域。

在PHP和Python之间进行选择:指南在PHP和Python之间进行选择:指南Apr 18, 2025 am 12:24 AM

PHP适合网页开发和快速原型开发,Python适用于数据科学和机器学习。1.PHP用于动态网页开发,语法简单,适合快速开发。2.Python语法简洁,适用于多领域,库生态系统强大。

PHP和框架:现代化语言PHP和框架:现代化语言Apr 18, 2025 am 12:14 AM

PHP在现代化进程中仍然重要,因为它支持大量网站和应用,并通过框架适应开发需求。1.PHP7提升了性能并引入了新功能。2.现代框架如Laravel、Symfony和CodeIgniter简化开发,提高代码质量。3.性能优化和最佳实践进一步提升应用效率。

PHP的影响:网络开发及以后PHP的影响:网络开发及以后Apr 18, 2025 am 12:10 AM

PHPhassignificantlyimpactedwebdevelopmentandextendsbeyondit.1)ItpowersmajorplatformslikeWordPressandexcelsindatabaseinteractions.2)PHP'sadaptabilityallowsittoscaleforlargeapplicationsusingframeworkslikeLaravel.3)Beyondweb,PHPisusedincommand-linescrip

PHP类型提示如何起作用,包括标量类型,返回类型,联合类型和无效类型?PHP类型提示如何起作用,包括标量类型,返回类型,联合类型和无效类型?Apr 17, 2025 am 12:25 AM

PHP类型提示提升代码质量和可读性。1)标量类型提示:自PHP7.0起,允许在函数参数中指定基本数据类型,如int、float等。2)返回类型提示:确保函数返回值类型的一致性。3)联合类型提示:自PHP8.0起,允许在函数参数或返回值中指定多个类型。4)可空类型提示:允许包含null值,处理可能返回空值的函数。

See all articles

热AI工具

Undresser.AI Undress

Undresser.AI Undress

人工智能驱动的应用程序,用于创建逼真的裸体照片

AI Clothes Remover

AI Clothes Remover

用于从照片中去除衣服的在线人工智能工具。

Undress AI Tool

Undress AI Tool

免费脱衣服图片

Clothoff.io

Clothoff.io

AI脱衣机

AI Hentai Generator

AI Hentai Generator

免费生成ai无尽的。

热工具

记事本++7.3.1

记事本++7.3.1

好用且免费的代码编辑器

SecLists

SecLists

SecLists是最终安全测试人员的伙伴。它是一个包含各种类型列表的集合,这些列表在安全评估过程中经常使用,都在一个地方。SecLists通过方便地提供安全测试人员可能需要的所有列表,帮助提高安全测试的效率和生产力。列表类型包括用户名、密码、URL、模糊测试有效载荷、敏感数据模式、Web shell等等。测试人员只需将此存储库拉到新的测试机上,他就可以访问到所需的每种类型的列表。

PhpStorm Mac 版本

PhpStorm Mac 版本

最新(2018.2.1 )专业的PHP集成开发工具

Atom编辑器mac版下载

Atom编辑器mac版下载

最流行的的开源编辑器

ZendStudio 13.5.1 Mac

ZendStudio 13.5.1 Mac

功能强大的PHP集成开发环境