ブロック、ノード、ビュー引数などでPHP Filterコードを使用することの欠点は何ですか？

ブロック、ノード、ビュー引数、ルールなどでカスタムのPHP / PHPフィルター（Drupal UIから）を使用しないと言っている人を何度も見ました。少し検索して、あまり見つけていないようです。これは、すべてが「知っている」Drupalのベストプラクティスです。

特にエンドユーザーまたはDrupalまたはPHPを初めて使用する人々の手に潜在的なセキュリティリスクをもたらすと理解していますが、開発者/サイトビルダーとしてDrupal UIからカスタムPHPを使用しない本当の理由は何ですか？

いくつかの理由：

• データベース内のコードはバージョン管理できず、一般的には後で見つけることも困難です。
• Eval（）されたコードは、ファイルにハードコードされたものよりもはるかに遅いです。
• そのコードのどこかにエラーがあると、非常に役に立たないエラーメッセージ（3行目のeval（） 'dコードのエラー）が表示され、データベースを手動で調べてエラーを見つけて修正することさえできます。すべてのページに表示されるブロック内にあり、たとえば常に致命的なエラーが発生する場合。
• 上記は、Drupal 6から7にアップグレードするときにも当てはまり、使用したAPIが変更されました。そのため、移行中にコードを移植する必要があります。コードがモジュール内にある場合は、事前に移植してテストし、新しいサイトにのみデプロイできます。ノードまたはブロック内では、Drupal 6または7でのみ機能します。
• ブラウザ内のテキストフィールドで作業しているため、そのコードの記述と保守も難しくなります。モジュールに含めると、構文の強調表示、オートコンプリートなどを備えたエディター/ IDEを使用できます。
• PHPの実行が有効になっていると、テキスト形式/ブロック/なんでもアクセスできるようにする設定ミスの可能性が常にあります。php.module（D7では、D6はブロックアクセスルールなどではそれほど厳密ではありません）が有効になっていない場合でも、そのリスクはすでにかなり低くなっています。
• CMSでPHPの実行が許可されている場合、XSSまたは権限昇格のセキュリティ脆弱性を発見した攻撃者は、サーバーを使用して非常に悪意のあるもの（DDOSの一部、スパムの送信、マルウェアのホスティング、他のサイト/データベースへのハッキング）に使用できるようになりますサーバー、ファイアウォールの背後にある可能性のあるネットワーク上の他のサーバーへのハッキング）。小さな脆弱性をより痛みのあるものにすることに加えて、PHPの実行に使用できることがわかっている場合、このサイトは攻撃の標的になる可能性が高くなります。

他にも理由があるかもしれませんが、それで十分でしょう:)

このコードはデバッグと保守が困難です。このような種類のphpコードにバージョン管理を使用する方法はわかりません。

そして、DrupalやPHPを初めて使用する人にとっては、潜在的なセキュリティリスクです。

ノードで使用されるPHPフィルターの場合を考えて、使用しない理由は、すべてのユーザーにPHPフィルターの使用を許可しない場合、そのノードを編集できるユーザーを制限するためです。
PHPフィルターを使用するよりも、ノードコンテンツの特定のテキストを（実行せずにeval()）実行するコードの結果で置き換える、またはノードの本文コンテンツに独自のテキストを追加するカスタムモジュールを使用することをお勧めします。この場合、任意のユーザーはノードを編集できますが、PHPフィルターによって実行される任意のPHPコードを追加する権限はありません。

一般に、eval()コードの読みやすさ、実行前にコードパス（およびその可能性のあるセキュリティへの影響）を予測する能力、したがってコードをデバッグする能力が低下するため、回避する方が適切です。

開発サイトやテストサイト以外では、PHPフィルターを有効にしたり、に渡されるPHPコードを使用したりしませんeval()。

PHPフィルターはDrupal 8から削除されました。現在、サードパーティのモジュールであり、セキュリティアドバイザリポリシーの対象外です。これはおそらく、本番サーバーで使用しない理由です（既に説明した理由で納得できない場合）。

上記で指定されたさまざまな問題の回避策として、コードのメンテナンス、バージョン管理、エラー検出の難しさとして、この「わずかな」可能性があります。

常にインクルードされるファイルに関数を作成します（その機能に応じて慎重に名前を付けます）-サイト用に作成しているカスタムモジュールがある場合は、これらの関数を配置するのに最適な場所です。あなたが入力したPHPは単純です：return my_specialfunc($somevar);- $somevarここでは、潜在的にノードオブジェクトは、作業中、または他のどんな変数がここに関連しています。

私は、通常、いくつかの場所で、自分のコードを呼び出す柔軟性が依然として必要だと感じています。この手法を使用する場合、ファイル内の関数を変更するだけなので、コードの保守は簡単です。関数はバックトレースに表示されるため、エラースポッティングは簡単です。

ただし、これは潜在的なセキュリティの問題を解決しないことに注意してください。これらは、Drupalコアのセキュリティに大きく依存しています。一般に、データベースに含まれるコードは、多くの場合、アキリーのセキュリティのかかとです。データベースに含まれるコードを使用する機能は、より悪用される傾向があり、それらの周りのセキュリティは厳しくする必要があります。ただし、Drupalは一般にこれらの問題のセキュリティを維持するのに非常に優れています。これらは発生し、新しいリリースですぐに修正/解決されました。

以下は、管理者以外のユーザーがdbを直接変更したくない場合に、ユーザーにこの許可を与えないようにするセキュリティ脆弱性の理由です。

<?php
echo file_get_contents(dirname(__FILE__)."/../sites/default/settings.php");
?>

Drupal db資格情報のハッキング

のようなreturn functionname($object)ことをするよりも、可能な限りトークン/フィルターシステムを使用する方が良いでしょう。挿入ビューや埋め込みノードなどのモジュールがあり、人々がPHPをノード本体またはブロック本体に埋め込みたいという一般的な状況に役立ちます。

データの移植性に注意する必要があります。ノードをdrupal 7からdrupal 8に移行し、一部のノードの本文に含ま<?php whatever_function_that_does_not_exist_anymore(); ?>れている場合はどうなりますか？

5か月以内ではなく5年以内にプロジェクトについて考えないでください。私の意見では、更新、優れた実践、移植性は、優れたITプロジェクトの重要な側面です。

貢献度の低いモジュールを可能な限り使用することも、この側面の1つです。