为什么Magento ECG编码标准中不允许这么多的PHP函数？

Magento ECG编码标准似乎（至少是某种形式）是Magento 1扩展的标准：

https://github.com/magento-ecg/coding-standard

但是我不理解所有规则背后的原因，仅代码嗅探器规则和它们的消息并没有多大帮助。是否有关于该标准的详细文档？我知道常见的最佳做法和开发人员指南，但找不到有关这些编码标准的任何具体信息。

最让我困扰的是不使用PHP函数的严格性。

例如：为什么每个与文件系统相关的PHP函数都被禁止？

我想，你应该使用Varien_Io_File，Varien_File_Object等等。但即使是核心开发人员不知道所有的瓦瑞恩类的，你经常会发现类似的事情在Mage_ImportExport_Model_Import_Adapter_Csv：

    $this->_fileHandler = fopen($this->_source, 'r');

因此，核心并非经常是最好的例子。

其他恕我直言的可疑禁用功能：

• mb_parse_str
• parse_str
• parse_url

• base64_decode

  • 是的，它用在后门中，但是禁止eval应该足够了，并且有合法的用例，例如编码二进制数据。除了json_decode（这是禁止的）以外，没有可用的核心帮助程序。

来源：https : //github.com/magento-ecg/coding-standard/blob/master/Sniffs/Security/ForbiddenFunctionSniff.php

本质上，我的问题可以归结为：该标准记录在哪里？和/或是否存在“代替这些本机PHP函数使用的东西”的列表？

得到了心电图小组的非正式答复：

首先，带标志的功能不一定是不允许的-它们应该触发使用情况的手动检查以确保合法使用。这是一个审查帮助工具，而不是好/坏代码评分工具。

其次，假设最好使用Magento包装器（函数/类）（如果存在的话），因为它们可能会提供其他功能或保护。

第三，对于特定的调用，base64_decode通常用于恶意注入的代码，而诸如parse_str之类的其余代码可能很容易受到攻击，尤其是处理未知或用户提供的输入时-例如，请参见http://php-security.org/2010/05/ 31 / mops-2010-049-php-parse_str-interruption-memory-corruption-vulnerability /

同样，这会将其标记为要审核，而不是拒绝将其视为错误代码。

希望能帮助到你。

编码标准有两个目标。

1. 使寻找可能有问题的零件变得容易得多。经验丰富的开发人员已经知道他需要检查新模块的哪些部分，并且该标准为他标记并列出了它们。并非如此，他可以删除此部分，而是查看它们是否是必要的，有问题的或两者兼有。

2. 支持没有经验的开发人员应该避免的事情。尽管所有标记的功能都可以解决特定问题，但它们很容易以有问题的方式使用。它使开发人员对问题进行更多的思考，并且通常会寻求与标准不冲突的更好的解决方案。

有时，即使最有经验的开发人员也盲目地遵循标准并创建最残酷的解决方法，只是为了不冒犯社区强制的标准。

一点其他信息

文件功能通常允许使用协议包装程序，这意味着以http：//开头的文件路径会导致http reaquest，这通常用于“打电话回家”，并且由于无法访问服务器，有时会杀死商店。 （默认为30秒超时），并将其内置在非常中央的位置。

无论使用哪种方式实现sql，没人相信那里仍然存在多少sql注入孔。一个很好的例子是，例如Mysql网站上的Search就有一个。

某处有一个用于json_decode的核心帮助程序，但是它有一个非常旧的实现，只需使用json_decode。不知道为什么应该禁止它。

gettext是一个有趣的php部分，我记得它使用了一些本机OS实施，如果您将其与其他语言同时使用时，可能会遇到问题（例如，通常在您的商店中只有一种以上的语言时会发生这种情况。 ，但在Magento上下文中也无需使用它。

再往下看，似乎只是一个具有尽可能多功能的列表。历史实际上是很有趣的，似乎他们从列表中删除了一些功能，他们注意到后便开始使用它。：D