Magento ECG Coding Standardで多くのPHP関数が許可されないのはなぜですか？

Magento ECG Coding Standardは、Magento 1拡張の標準として（少なくとも一種）公式であるようです：

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

しかし、私はすべてのルールの背後にある理由を理解していません。また、メッセージだけのコードスニッファールールはあまり役に立ちません。標準に関する詳細なドキュメントはありますか？一般的なベストプラクティスと開発者ガイドは知っていますが、これらのコーディング標準に関する具体的な情報は見つかりません。

私が最も悩むのは、PHP関数を使用しないことに関する厳格さです。

たとえば、PHP関数に関連するすべてのファイルシステムがすべて禁止されているのはなぜですか？

私はあなたが使用することになっている、と思うVarien_Io_File、Varien_File_Objectなどそれでもコア開発者は、すべてのVarienクラスを認識していないと、あなたは、多くの場合でのようなものを見つけますMage_ImportExport_Model_Import_Adapter_Csv：

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

そのため、多くの場合、コアは最良の例ではありません。

他のIMHOの疑わしい禁止機能：

• 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関数の代わりに使用するもの」のリストはありますか？

それについてECGチームから非公式の回答を得ました：

まず第一に、フラグが立てられた機能は必ずしも許可されないわけではありません-それらは合法的な使用を確実にするために使用法の手動レビューを引き起こすべきです。これはレビューヘルパーツールであり、良い/悪いコードスコアリングツールではありません。

第二に、Magentoラッパー（関数/クラス）が存在する場合、追加の機能または保護を提供する可能性があるため、Magentoラッパー（関数/クラス）を使用する方が良いという前提がありました。

第三には、特定の呼び出しのためとして、BASE64_DECODEは、悪意のあるコードを注入するために頻繁に使用され、parse_strなどの残りの部分は、特に、未知またはユーザー提供の入力を処理し、脆弱かもしれません-例えば参照http://php-security.org/2010/05/ 31 / mops-2010-049-php-parse_str-interruption-memory-corruption-vulnerability /

繰り返しになりますが、これはレビューのためにフラグを立て、コードを不良として拒否しません。

それが役に立てば幸い。

コーディング標準には2つの目標があります。

1. 問題のある可能性のある部品を簡単に見つけることができます。経験豊富な開発者は、新しいモジュールのどの部分をレビューする必要があるかを既に知っており、この標準はそれらをマークしてリストします。彼がこの部分を削除できるわけではありませんが、必要であるか、問題があるか、またはその両方であるかを確認します。

2. 経験の浅い開発者がサポートすべきことをサポートします。マークされたすべての機能は特定の問題に対して優れたソリューションになる可能性がありますが、問題のある方法で使用するのは非常に簡単です。開発者は問題についてより多くのことを考えるようになり、多くの場合、標準と矛盾しないより良い解決策になります。

そして、時々、経験豊かな開発者でさえ、盲目的に標準に従い、最も残酷な回避策を作成します。これは、コミュニティが強制する標準を傷つけないためです。

少し追加情報

ファイル関数はしばしばプロトコルラッパーの使用を許可します。これは、http：//で始まるファイルパスがhttp reaquestにつながることを意味します。 （デフォルトのタイムアウトは30秒）と、非常に中心的な場所に組み込まれています。

すべてのSQLが実現しましたが、SQLインジェクションホールがまだいくつ存在するかは誰も信じていません。Mysql Webサイトの検索には1つの例がありました。

json_decodeのコアヘルパーはどこかにありますが、非常に古い実装であるため、json_decodeを使用してください。なぜそれが禁止されるべきか考えがありません。

gettextは興味深いphpの部分です。異なる言語の並列で使用すると、問題が発生する可能性のあるネイティブOS実装を使用していることを覚えています（通常、ショップに複数の言語がある場合に発生します。 、しかし、Magento Contextでも必要ないはずです。

リストをさらに調べてみると、それは可能な限り多くの機能を備えた単なるリストのようです。歴史は実際に面白いです、彼らはリストからいくつかの機能を削除したようです、彼らが気づいた後、彼らはそれを利用します。：D