4.11　PEAR::Text_CAPTCHA——实现垃圾信息对策程序

在现在的网络世界中，到处存在由垃圾信息、病毒引起的网络攻击。那些拥有自己的网站或博客的朋友，肯定有被那些垃圾信息困扰的经验吧。在大多数情况下，通常那些不怀好意的人会使用一种叫做Bot的程序，来向网站或博客进行自动的提交垃圾信息。而制作Bot程序的门槛并不高，大家使用后面的Zend_http组件就可以开发出具有基本功能的Bot程序（在此不是鼓励去开发这种Bot程序）。

那怎样才能对付这种Bot程序的威胁呢？本节就介绍一种对付垃圾信息（或称Bot程序）的方法，称为CAPTCHA（Completely Automated Public Turing test to tell Computers and Humans Apart）。CAPTCHA技术就是，以故意显示不易识别的文字图片为特征，提交认证结果。而用户识别出这些字符串，并在按下“提交”按钮前输入这些字符串。而在一般情况下计算机是很难识别这些字符串的，而只有在正确输入这些字符串后，才能提交。

CAPTCHA技术并非垃圾信息对策的万全之策，但可以说是有效的对策。本节将介绍如何利用CAPTCHA技术完成这个垃圾信息对策程序。

本例要点

为了生成CAPTCHA图片，这里使用了PEAR::Text_CAPTCHA程序库。使用PEAR::Text_CAPTCHA程序库时，只要传入必要的参数，就能生成CAPTCHA图片。

本节的例子只是单纯的CAPTCHA图片识别的例子，在实际的应用程序的情况下，正确识别后，还有将实际输入数据保存到数据库的处理。程序库本身的使用方法很简单，可以以实际开发应用程序的感觉去揣摩下面的代码。

目录结构

本例代码

初次显示时（即没有发生提交的动作）运行6到22行的代码，生成CAPTCHA图片。

使用Text_CAPTCHA类来生成CAPTCHA图片。首先使用factory方法生成Text_CAPTCHA对象。factory方法参数中指定内部使用的驱动。这里为生成图片，所以固定为image。

init方法中设置图片生成时需要的参数信息，这里都是需要设置的最基本的参数，依次为width（图片宽度）、height（长度）、output（输出形式）、imageOption（使用的字体、字体文件）。

session_id函数返回现在的sessionID，这个sessionID将作为保存CAPTCHA图片的临时文件名。例如会生成“./img/4gdegdadgga9aga89aasdf3.png”这样的文件名，再将其保存在session信息name中，后面要用到。

7行到18行指定的信息为基础，生成PNG类型的CAPTCHA图片，file_put_contents函数会将图片保存在session信息name所示的路径中。

getPhrase方法返回图片中埋藏的字符串，并把这个字符串保存在session信息captcha中，在进行识别判断时会用到这个保存的session信息。

按下“提交”按钮时，运行24行到31行。

这里，将对提交过来的值$_POST['captcha']与session中保存的值$_SESSION['captcha']进行比较，相等说明是正确的提交，反之为不正确。

判定结束后，破坏session以及临时图片文件。

设置为向自己提交。由$_POST['submit']的值来判断是否提交。

在<img>中显示生成的图片。

补充

本例注意事项

本节中使用的PEAR::Text_CAPTCHA库，是PEAR提供的库之一，使用前必须进行库的安装。具体的步骤如下。

另外，PEAR::Text_CAPTCHA库需要使用GD2程序库以及为了生成画像所需要的font文件。可以参照上一节的内容进行配置。

Session

在Web应用程序中，经常需要在多个页面之间传递信息。就如本节一样，需要将CAPTCHA图片中包含的字符串保存到提交后判定的时候。

但是，被称为Web应用程序基础的HTTP（HyperText Transfer Protocol）协议，并不能管理状态。HTTP的作用范围限制在用户提交需求，然后返回应答为止。这样简单的通信方式在Web的发展、普及过程中发挥了巨大的作用，但是在多页面应用程序中，光有HTTP协议是不够的。

我们可以想象一下那些需要登录（login）的应用程序，HTTP不能管理“已经登录”这个状态。总之，HTTP能管理“用户ID与密码提交到服务器了”“服务器验证通过了”，到“返回验证应答页面”为止。结果就是用户在连接所有的网页前，都必须进行登录处理。

在这样的情况下，就不能实现了应用程序的某些功能。因此，后来采取在Query信息，或Cookie，隐藏框中保存状态的手段来，解决上述问题。这些手段都不怎么理想，当需要保存的信息太多，采取在Query信息或隐藏框中保存信息的方式，不太现实，因为所有关联的页面都得保存这些相同的信息，容易出错。当使用Cookie来保存信息时，要受客户端设置的限制，当客户端设置不能使用Cookie时，手段就失效了。而且，上述所有手段，包括Cookie方式，在安全上都有问题，信息容易被盗取。

这时候，出现了Session这种手段。Session将一系列的页面看做一个应用程序，以用户为单位管理信息的构造。尽管是以用户为单位管理着所有信息，信息本身是保存在服务器上的。客户端只是管理SessionID这个标示。不用担心会向客户端画面传递Session信息。

Session保存的机制如图4-3所示。

图4-3　Session保存的机制

当然，如果泄露了SessionID，是可以看得到相关数据的。因此不能说Session绝对安全。但是，SessionID只是个临时的主键，只要适时通信没有被监视，发生数据盗用的情况几乎是不可能的。今后，在推荐使用Session在多个页面间传递信息。

就像例子中显示的样，使用全局变量$_SESSION来进行Session的存取。