PHPフィルターコードをブロック、ノード、ビュー引数などで使用することの欠点は何ですか？
ブロック、ノード、ビュー引数、ルールなどで（Drupal UIからの）カスタムPHP/PHPフィルターを使用しないことを言っている人々を何度も目にしました。少し調べてみましたが、多くが見つかりました、これはDrupalのベストプラクティスであり、すべて「知っている」だけのようです。
特にDrupalまたはPHPを初めて使用するエンドユーザーまたは人々の手に潜在的なセキュリティリスクをもたらすことを理解していますが、開発者/サイトビルダーとして、カスタムを使用しない本当の理由PHP Drupal UIから？
いくつかの理由：
- データベース内のコードはバージョン管理できず、一般的に後で見つけるのも困難です。
- Eval（）されたコードはmuchファイルにハードコードされたものよりも低速です。
- そのコードのどこかにエラーがあると、非常に役に立たないエラーメッセージ（3行目のeval（）のコードのエラー）が表示され、データベースを手動で調べてエラーを見つけて修正することもできます。たとえば、すべてのページに表示され、常に致命的なエラーが発生するブロック内にある場合。
- 上記は、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.から削除されました。これは現在 サードパーティモジュール であり、- セキュリティ勧告ポリシー 。これは、おそらく本番サーバーでそれを使用しない理由です（すでに与えられた理由で納得しなかった場合）。
管理者以外のユーザーにdbを直接変更させたくない場合に、ユーザーにこの権限を与えないようにするセキュリティの脆弱性の理由を次に示します。
<?php
echo file_get_contents(dirname(__FILE__)."/../sites/default/settings.php");
?>
Drupal db credentials のハッキング
上記で指定されたさまざまな問題の回避策として、コードのメンテナンスの難しさ、バージョン管理、エラーの発見など、わずかに「klugey」の可能性があります。
常に含まれているいくつかのファイルに関数を作成します（機能に応じて慎重に名前を付けます）。サイト用に作成しているカスタムモジュールがある場合、これらの関数を配置するのに最適な場所です。次に入力するphpは単純です：return my_specialfunc($somevar);-$somevarここでは、作業対象のノードオブジェクトである可能性があります。
たいていの場合、自分のコードを呼び出す柔軟性が必要な場合があります。この手法を使用すると、ファイル内の関数を変更するだけなので、コードの保守が簡単になります。関数はバックトレースに表示されるため、エラーの特定は簡単です。
ただし、これは潜在的なセキュリティ問題を解決しないことに注意してください。これらは、Drupalコアのセキュリティに大きく依存します。一般に、データベースに含まれるコードは、多くの場合、セキュリティのアヒルのかかとです。データベースに含まれるコードを使用する機能は、悪用、およびそれらの周りのセキュリティは非常に厳格である必要があります。ただし、Drupalは一般に、これらの問題のセキュリティを維持するのに非常に優れています。 。
return functionname($object)のようなことをするのではなく、可能な限りトークン/フィルターシステムを使用することをお勧めします。 Insert ViewやEmbed Nodeのようなモジュールがあります。これは、ノードまたはブロックの本体にPHPを埋め込む必要がある一般的な状況に役立ちます。
データの移植性に注意する必要があります。ノードをdrupal 7からdrupal 8に移行し、一部のノードの本文に<?php whatever_function_that_does_not_exist_anymore(); ?>が含まれている場合はどうなりますか？
5か月以内ではなく5年以内にプロジェクトについて考えないでください。私の意見では、更新、優れた実践、および移植性は、優れたITプロジェクトの重要な側面です。
貢献度の低いモジュールをできるだけ使用することも、この1つの側面です。