3

我想知道在较低级别代码中嵌入诸如散列和加密之类的东西的常见做法。似乎最好使用某种对象或宏约定，以便在发现漏洞并提高效率时可以轻松评估和更新安全功能。例如，我在处理身份验证的 PHP 代码中看到了以下约定（博客、代码峡谷、框架 wiki 等）……这是一个虚构的例子来说明这一点。

if ($myhash !== md5(shaX($this->key) . blah($this->salt) . blah($this->var))

而不是把它埋得很深，这不是更好吗？

if ($myhash != MY_HASH($key))

在配置文件或其他易于访问的对象中使用 MY_HASH，从而在可用时更容易更新/维护并具有更好的安全性？为什么不将任何加密或散列的金块放入仅包含转换函数的配置文件或特殊散列文件中？

另外 - 考虑数据库访问。PHP 有很多抽象，但我看到应用程序这样做：

// grab some data from the database
if ($this->mongo_flag)
{
    $this->mongo_abstraction
    ->where($blah1, $x)
     ->update($blah2);
}
elseif ($this->mysql_flag)
{
    $this->mysql_abstraction
    ->where($blah1, $y)
     ->update($blah2);
}
elseif ($this->couch_flag)
{
    $this->couch_abstraction
    ->where($blah1, $z)
     ->update($blah2);
}

也许只有 x,y,z 不同。

不能实例化一个预先具有适当 db 方法的对象，从而消除 if/else 逻辑，该逻辑在进行数据库访问的任何地方都重复出现？

IE

$mydata = $this->db_get_method($blah1, $blah2);

或者

$mydata = $DB_GET_METHOD($db_type, $blah1, $blah2);

当首选 if/else 歧视时，您似乎应该跳过抽象的东西，而只使用本机 API，使其更高效、更易于维护，因为本机 api 可能不会改变，并且抽象大多无效/voided 通过调用每个可能的数据库类型。或不？

My main experience is with real-time embedded C programming (a lot of PHP code looks like procedural C designed with global structs) so I'm wondering whether performance might be the definitive answer, i.e. it just runs faster this way? Do objects introduce too much latency/complexity?

4

3 回答 3

0

我喜欢你的建议。特别是对于散列，我认为将其包装到一个易于访问的位置是明智的。我也喜欢你关于调用 db 方法的建议。但是，使用 PHP 执行您的建议需要反射，并且存在性能问题，请查看这篇文章PHP 5 Reflection API performance。性能冲击似乎并不算太​​糟糕，但性能仍有下降。我认为实现 db 方法调用的更好方法是使用 OOP 继承而不是传递动态方法。每个数据库应该有一个不同的对象。

于 2012-07-20T18:45:04.517 回答
0

正如@complex857 在他的评论中所说，PHP 有一些努力来简化散列过程。无论如何，您可以自己完成它们（简单的函数，或更复杂的类）。

也许我没有理解你的权利，但是关于 DB 抽象，使用 PHP PDO（以及 PEAR 的 DB 和 MDB2）你可以为特定的 DB 引擎构建一个对象，然后，方法大致相同（出现差异仅在处理任何引擎的特定功能时）。

还有一个关于 PHP 的大问题：有时您会偶然发现编写得非常糟糕的脚本，可能是由业余程序员编写的。因此，如果您多次看到相同的不良做法，这并不意味着使用 PHP 没有更好的方法。还要考虑这些脚本的历史：PHP 在其生命周期中已经发展了很多。

于 2012-07-20T19:01:46.673 回答
0

身份验证和数据库抽象都是常见的痛点。程序员的狂妄自大或缺乏经验确实会导致大量糟糕的再发明（以及偶尔有用的创新）。

就数据库抽象而言，当后端实现显着不同时，您的示例很快就会崩溃。例如，Couch 或 MongoDB 等 NoSQL 数据库的查询语言和数据建模与 SQL 数据库使用的传统关系查询不能很好地匹配。你最终会得到一个泄漏的抽象，你要么使用一个“通用”接口，其中有很多关于给定后端的工作原理的警告......要么是一个严格限制的最低公分母。这是ORM的一个常见问题。它们经常难以表示不太适合预期的 ObjectClass <=> DatabaseTable 映射的连接或子选择。

即使在“类似”产品（例如支持SQL等通用关系语言的数据库）中也是如此。每个数据库通常都有自己的 SQL 方言，这些方言通常从支持的数据类型开始，并且随着实现扩展到触发器、存储过程和视图等更高级的特性而变化更大。

从您的其他示例的外观来看，您还遇到了一些意大利面条式代码，其中开发人员可能在实现自己的抽象方面做得很差。

如果性能是一个问题，最好的结果可能是针对特定的数据库后端进行优化并利用独特的功能。

如果支持多种数据库后端更为优先，则有标准的关系接口，例如PDO、Doctrine或MDB。一种新兴的数据库抽象类别是用于 MongoDB 和 Couch 等 NoSQL 数据库的 ODM（对象文档映射器）。

于 2012-07-24T14:37:06.123 回答