我们的开发团队刚刚将一个应用程序从本地服务器迁移到实时站点。该应用程序利用可写入的远程数据库,并利用 MSQLi 和 PDO 方法获取数据并将数据推送到数据库。
更新 connect .inc 文件以获得正确的数据库凭据后,Web 应用程序将在后端运行。数据通过表单进入数据库。但是,由于某种原因没有设置 session 变量。现在,我留下了一个邪恶的、几乎是传统的网络开发问题:
"why does it work on the local server but not on the live site?"
我做了一个快速 session 测试,其中设置并回显了一个虚拟 session 变量,它像铃声一样响起。问题来自设置 session 后查询。也就是说,在查询运行后,传递的数据会再次清理并传递给 session 变量。下面是一个很好的例子。
if ($query_dummy = $query_putitthere)
{
$_SESSION ['name'] = $name;
$_SESSION ['date of application'] = $date;
$_SESSION ['certifications'] = $certs;
$_SESSION ['address'] = $addr;
header ('Location: next_page.php');
}
就像一个优秀的小 PHP 开发人员一样,OB_start
和 session_start
都位于 PHP 文档的顶部,并且它们再次使用相同的代码在本地服务器上工作。我唯一能想到的问题是,当我们更改新数据库的凭据时发生了一些事情,但这没有太大意义,因为数据正在顺利地进入数据库。
我怀疑这是一个 PHP 配置问题,因为您认为无论运行什么版本, session 和 PHP 在处理方面的行为都必须保持一致。然而,奇怪的事情发生了。
变量在前端通过msqli_real_escape _string
进行清理。举例如下。
$name = mysqli_real_escape_string($connect, $_POST['your_name']);
$date = mysqli_real_escape_string($connect, $_POST['date_of_app']);
$certs = mysqli_real_escape_string($connect, $_POST['certifs']);
我意识到当我说他们在参加 session 之前再 sanitizer 一次时我可能说错了。实际上,当 session 通过时,它们会通过 html_enttites
在第二页上进行清理。
MSQLi 负责处理用户输入的卫生信息,而 html_entities 处理任何可能从后端的裂缝中溜走的侥幸。
最佳答案
如果没有办法重现该行为,就很难确定确切的原因,但您可能需要仔细检查以下几点:
session cookie 是否发送到浏览器?这是作为 HTTP
Cookie
header 发送的,因此它需要在您的脚本向客户端发送任何输出之前发生。浏览器的 cookie 是否返回到服务器?跨不同域或子域写入和读取 cookie 可能会导致问题。
这里我们讨论的 session 数据有多少?我不熟悉存储的 session 文件的任何大小限制,但如果你正在调情 php.ini 的
memory_limit
事情可能会变得很奇怪。session 文件存储在磁盘的什么位置?如果他们进入
/tmp
,在您有机会再次读取文件之前,是否可以运行像tmpwatch
这样的进程并修改文件?是session GC variables在 php.ini 中设置得太激进?您能找到相关 session 的文件吗?里面是什么?它的内容应该可以用
unserialize()
解析,它也是人类可读的。您的示例显示您设置了
$_SESSION
,然后立即执行 HTTP 重定向。你被咬了吗this ancient, possibly fixed WebKit bug ?
关于现场 PHP session 问题但不是本地问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23798931/