由于服务器损坏 ,所以不得不重新发布网站。当 Anakin 兄弟全部将环境搞定,并且 Gracecode.com 也能正常浏览的时候,我发现我的网站竟然不能登录了。
起初,我怀疑是环境问题,于是我联系 Anakin 兄,他说一切正常。于是,我就开始检查起我的代码,几段 DEBUG 代码下来,我发现竟然连 POST 数据都收不到(var_dump($_POST);),而 GET 是正常的!非常地让人匪夷所思。
继续 DEBUG 发现,我输错了用户名和密码是能 var_dump 出 POST 与 SESSION 的,一切正常。唯独就是我输入正确的用户名与密码以后,老问题就出现了。
经过充分的调试与徘徊以后,我开始静下心来思索 Session 的流程:Session 由客户端的 Cookie(或者是其他验证方式)提供验证值,然后服务器端根据这个值,从文件系统(或者数据库、或者内存文件系统、任何你想得到的媒介)获得对应的值。
那么先从客户端入手,看看是否存在异常。首先,查看客户端是否有保存的 Cookie,的确是有的 -- 这就证明客户端是没有问题的。继续推断,既然客户端方面问题不大,那么问题到底是出在哪里呢?
登录不进去,那么我将判断是否登录的函数修改成始终返回 true(请未成年的小朋友在家长的陪同下操作)。发现登录后台与操作一切都没有问题的,这就说明 POST 过去的数据服务器也是能够接收的。
那么,单从这点上说明,肯定是服务器端的 Session 出了问题。我打印出 Session 的配置,如下图。
根据我的经验,并没有发现配置上有什么异常的地方。此时,我突然有种「邪恶」的想法,于是乎就 DEBUG 了下述的代码
var_dump(is_writeable(ini_get("session.save_path")));
噢,「卖蛋糕、牙膏、×膏药」的!竟然返回的是 false,看来 Anakin 这小子又要被我「诅咒」了。问题终于有了个水落石出的结果,原来新安装好的系统,忘记把 session.save_path 设置成可写的了。这样导致登录成功以后,需要写入的 Session 无法保存在文件系统中,而此时 Session 的的确确有又是 start 的。
绕过这一问题很简单,只需要在 session_start 之前用 session_save_path 设置成自己的某个可读的目录就可以了。
马上联系 Anakin 兄那小子,并将相应的目录修改了回来。证明我的推断是正确的,现在又可以登录进去了。至于 POST 为何无法接收到,在事后也找到了原因,是因为 301 重定向带到了新的页面。
看来,忙乱中,总是会出现不大不小的问题,共勉之。