首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

ThinkPHP类似AOP思想的参数验证的实现方法

思路讲解:不管是在开发 API 还是做后台项目的时候,后端永远不要相信前端传输的参数,通常要做的是验证参数的合法性和安全性。那么在实际项目开发的时候,怎么简便的验证参数呢。TP 提供了好几种参数验证的方式,比如验证器,独立验证,又或者在继承 Controller 基类的情况下使用 validate 方法。相比而言,验证器还是最佳选择。一个控制器有多个方法,也就表示有多个请求,也就表示有多个场景。一个项目不止一个控制器,那就表示不止需要建立一个验证器。面向对象的思想,就需要我们建立一个基类验证器,然后让子类继承就行了。那么怎么实现参数验证呢,下面我就介绍下类似 AOP 思想的参数验证的实现。

01

ThinkPHP类似AOP思想的参数验证的实现方法

思路讲解:不管是在开发 API 还是做后台项目的时候,后端永远不要相信前端传输的参数,通常要做的是验证参数的合法性和安全性。那么在实际项目开发的时候,怎么简便的验证参数呢。TP 提供了好几种参数验证的方式,比如验证器,独立验证,又或者在继承 Controller 基类的情况下使用 validate 方法。相比而言,验证器还是最佳选择。一个控制器有多个方法,也就表示有多个请求,也就表示有多个场景。一个项目不止一个控制器,那就表示不止需要建立一个验证器。面向对象的思想,就需要我们建立一个基类验证器,然后让子类继承就行了。那么怎么实现参数验证呢,下面我就介绍下类似 AOP 思想的参数验证的实现。

04
您找到你想要的搜索结果了吗?
是的
没有找到

PHP会话(Session)实现用户登陆功能

对比起 Cookie,Session 是存储在服务器端的会话,相对安全,并且不像 Cookie 那样有存储长度限制,本文简单介绍 Session 的使用。 由于 Session 是以文本文件形式存储在服务器端的,所以不怕客户端修改 Session 内容。实际上在服务器端的 Session 文件,PHP 自动修改 Session 文件的权限,只保留了系统读和写权限,而且不能通过 ftp 修改,所以安全得多。 对于 Cookie 来说,假设我们要验证用户是否登陆,就必须在 Cookie 中保存用户名和密码(可能是 md5 加密后字符串),并在每次请求页面的时候进行验证。如果用户名和密码存储在数据库,每次都要执行一次数据库查询,给数据库造成多余的负担。因为我们并不能 只做一次验证。为什么呢?因为客户端 Cookie 中的信息是有可能被修改的。假如你存储 $admin 变量来表示用户是否登陆,$admin 为 true 的时候表示登陆,为 false 的时候表示未登录,在第一次通过验证后将 $admin 等于 true 存储在 Cookie,下次就不用验证了,这样对么?错了,假如有人伪造一个值为 true 的 $admin 变量那不是就立即取的了管理权限么?非常的不安全。 而 Session 就不同了,Session 是存储在服务器端的,远程用户没办法修改 Session 文件的内容,因此我们可以单纯存储一个 $admin 变量来判断是否登陆,首次验证通过后设置 $admin 值为 true,以后判断该值是否为 true,假如不是,转入登陆界面,这样就可以减少很多数据库操作了。而且可以减少每次为了验证 Cookie 而传递密码的不安全性了(Session 验证只需要传递一次,假如你没有使用 SSL 安全协议的话)。即使密码进行了 md5 加密,也是很容易被截获的。 当然使用 Session 还有很多优点,比如控制容易,可以按照用户自定义存储等(存储于数据库)。我这里就不多说了。 Session 在 php.ini 是否需要设置呢?一般不需要的,因为并不是每个人都有修改 php.ini 的权限,默认 Session 的存放路径是服务器的系统临时文件夹,我们可以自定义存放在自己的文件夹里,这个稍后我会介绍。 开始介绍如何创建 Session。非常简单,真的。 启动 Session 会话,并创建一个 $admin 变量:

02

2018-09-12 小白必须懂的`MongoDB`的十大总结

MongoDB 是一个介于关系数据库和非关系数据库之间的开源产品,是最接近于关系型数据库的 NoSQL 数据库。它在轻量级JSON 交换基础之上进行了扩展,即称为 BSON 的方式来描述其无结构化的数据类型。尽管如此它同样可以存储较为复杂的数据类型。它和上一篇文章讲到的Redis有异曲同工之妙。虽然两者均为 NoSQL ,但是 MongoDB 相对于 Redis 而言,MongoDB 更像是传统的数据库。早些年我们是先有了 Relation Database (关系型数据库),然后出现了很多很复杂的query ,里面用到了很多嵌套,很多 join 操作。所以在设计数据库的时候,我们也考虑到了如何应用他们的关系,使得写 query 可以使 database 效率达到最高。后来人们发现,不是每个系统,都需要如此复杂的关系型数据库。有些简单的网站,比如博客,比如社交网站,完全可以斩断数据库之间的一切关系。这样做带来的好处是,设计数据库变得更加简单,写 query 也变得更加简单。然后,query 消耗的时间可能也会变少。因为 query 简单了,少了许多消耗资源的 join 操作,速度自然会上去。正如所说的, query 简单了,很有以前 MySQL 可以找到的东西,现在关系没了,通过 Mongo 找不到了。我们只能将几组数据都抓到本地,然后在本地做 join ,所以在这点上可能会消耗很多资源。这里我们可以发现。如何选择数据库,完全取决于你所需要处理的数据的模型,即 Data Model 。如果它们之间,关系错综复杂,千丝万缕,这个时候 MySQL 一定是首选。如果他们的关系并不是那么密切,那么, NoSQL 将会是利器。

02
领券