从 mysql_query 切换到 PDO 的问题

Question

我正在从传统的 mysql_query() 参数化查询切换到 PDO，以利用它的安全优势，但我有几个问题。首先，就 magic_quotes 而言，是否需要做任何事情？该网络应用程序将安装在不同配置的系统上，有些系统（不幸的是）会打开它们，而另一些则关闭。以前，当关闭输入数据时，我正在对 addslashes() 执行整个 if 语句...使用这样的 PDO 查询需要做什么：

$dbh = new PDO("mysql:host=$db_server;dbname=$db_database", $db_username, $db_password);
$sth = $dbh->prepare("SELECT * FROM `users` WHERE `username` = :username ");
$sth->bindParam(':username', $_POST['username']);
$sth->execute();
if($row = $sth->fetch()){
    // Yup
}
$dbh = null;

另外，关闭数据库处理程序有什么必要到底？不这样做有什么坏处？对于将安装在许多不同服务器设置上的 CMS，PDO 是一个不错的选择吗？ PDO 是否足够普遍，大多数服务器都会启用它？

提前致谢！

Answer 1

此网络应用程序将安装在不同配置的系统上，有些系统（不幸的是）会打开 [magicquotes]，而另一些则关闭。

正如我在另一个答案的评论中指出的那样，PHP 手册有整个部分< /a> 关于处理恐怖的事情就是魔法引述。您通常可以在 .htaccess 中本地禁用它，或者在数据传入时更正数据。我个人不会与默认启用它的托管提供商开展业务。

以前，当关闭输入数据时，我会对 addslashes() 执行整个 if 语句

哎呀！ addslashes 没有提供足够的保护。使用旧的 MySQL 扩展时，需要设置字符集后使用mysql_real_escape_string。 如果不这样做可能会让您面临巨大的漏洞。

...需要对这样的 PDO 查询执行什么操作：

除了设置连接字符集之外，什么都没有！ PDO 将尽可能使用真正的准备好的语句。这意味着它首先将带有占位符的查询发送到服务器，以便服务器可以处理它，然后它会单独发送参数。这使得查询免受 SQL 注入的影响。

（某些数据库不支持 PDO 准备好的语句。对于这些数据库，PDO 将处理查询，用带引号的转义值替换占位符。结果是相同的 - 免受 SQL 注入的影响。）

另外，最后有必要关闭数据库处理程序吗？不这样做有什么坏处？

就像其他 PHP 数据库处理程序一样，不需要关闭连接——当脚本结束时，连接将关闭。 （甚至不要考虑持久性连接。）

对于要安装在许多不同服务器设置上的 CMS，PDO 是一个不错的选择吗？ PDO 是否足够普遍，大多数服务器都会启用它？

PDO 在 PHP 5.1 中成为标准，但这并不意味着它始终可用。大多数 Linux 发行版都将 PHP 的所有数据库访问选项分开，以便在安装它们的同时也安装必需的库。有时，不称职或缺乏经验的托管提供商不会安装 PDO 包来与其他数据库访问选项一起安装，也没有意识到他们在做什么。通常可以通过简单地要求他们启用 PDO 并在他们不愿意或无法时切换到另一台主机来纠正此问题。

许多现代框架更喜欢在 PDO 之上构建，但也提供其他选项。例如，Zend Framework 的 Zend_Db 具有 PDO、mysqli 的适配器，以及其他一些。如果您担心 PDO 并不总是可用，那么使用适配器层可能会很适合您。 （与大多数 ZF 组件一样，Zend_Db 并不严重依赖其他 ZF 组件，这意味着您可以轻松地将其与代码捆绑在一起。）

Answer 2

我不会太担心 magic_quotes。 PDO 是在 PHP 5.1 中引入的，当时 magic_quotes 默认关闭了一段时间。应该有非常非常少的主机支持 PDO 但启用了 magic_quotes。

如果您仍然想处理这个小百分比，我建议您简单地修改 $_GET、$_POST 和 $_COOKIE 全局变量，并去掉 magic_quotes 添加的斜线。或者，如果您不想直接更改它们，请将它们包装在某种 Request 对象中。