Quais são as desvantagens de usar o código PHP Filter em blocos, nós, views-args, etc?

Eu já vi muitas vezes pessoas dizendo para não usar filtro PHP / PHP personalizado (da Drupal UI) em blocos, nós, modos de exibição de argumentos, regras etc. Eu pesquisei um pouco e não encontrei muito, parece que essa é uma prática recomendada do Drupal que todos "apenas conhecem".

Entendo que isso representa um risco potencial à segurança, especialmente nas mãos de usuários finais ou pessoas novas no Drupal ou PHP, mas como desenvolvedor / construtor de sites, quais são os verdadeiros motivos para não usar PHP personalizado na interface do usuário do Drupal?

Algumas razões:

• O código no seu banco de dados não pode ser controlado por versão e também é mais difícil de encontrar em geral mais tarde.
• O código de Eval () é muito mais lento do que algo codificado em um arquivo.
• Se houver um erro em algum lugar desse código, você receberá uma mensagem de erro muito inútil (erro no código eval () na linha 3) e pode até ter passado pelo seu banco de dados manualmente para encontrar e corrigir o erro. Se estiver dentro de um bloco que é exibido em todas as páginas e resultar em um erro fatal o tempo todo, por exemplo.
• O exposto acima também é verdadeiro ao atualizar do Drupal 6 para 7 e quaisquer APIs usadas foram alteradas. Portanto, você terá que portar seu código durante a migração. Se o código estiver em um módulo, você poderá portá-lo com antecedência, testá-lo e implantá-lo apenas no novo site. Dentro de um nó ou bloco, ele funcionará apenas com o Drupal 6 ou 7.
• Escrever e manter esse código também é mais difícil, porque você está trabalhando em um campo de texto dentro do navegador. Tê-lo em um módulo permite que você use um editor / IDE com destaque de sintaxe, preenchimento automático e assim por diante.
• Sempre existe a possibilidade de uma configuração incorreta que dá às pessoas acesso a um formato / bloco de texto / qualquer coisa com a execução do php ativada. Se o php.module (em D7, D6 não for tão rigoroso, por exemplo, para regras de acesso de bloco) nem estiver ativado, esse risco já será muito menor.
• Se o seu CMS permitir a execução do PHP, um invasor que encontrar uma vulnerabilidade de segurança do XSS ou a escalação de privilégios agora poderá usar o servidor para coisas extremamente maliciosas (como parte de um DDOS, enviando spam, hospedando malware, invadindo outros sites / bancos de dados no servidor, invadindo outros servidores da rede que possam estar protegidos por firewalls). Além de tornar as pequenas vulnerabilidades mais dolorosas, isso torna o site um alvo de ataque mais provável, se soubermos que ele pode ser usado para executar o php.

Pode haver mais razões, mas isso deve ser suficiente :)

É difícil depurar e manter esse código. Não conheço nenhuma maneira de usar o controle de versão para esse tipo de código php.

E é realmente um risco de segurança potencial para pessoas novas no Drupal ou PHP,

Considerando o caso do filtro PHP usado em um nó, o motivo para não usá-lo é que você limita os usuários que podem editar esse nó, se não desejar permitir que todos os usuários usem o filtro PHP.
Em vez de usar o filtro PHP, é melhor usar um módulo personalizado que substitua texto específico no conteúdo do nó pelo resultado do código que ele executa (sem usar eval()) ou que acrescente seu próprio texto ao conteúdo do corpo dos nós. Nesse caso, qualquer usuário pode editar o nó, sem ter a permissão para adicionar código PHP arbitrário que é executado pelo filtro PHP.

Geralmente, é melhor evitar, eval()pois diminui a legibilidade do código, a capacidade de prever o caminho do código (e possíveis implicações de segurança) antes do tempo de execução e, portanto, a capacidade de depurar o código.

Além de um site de desenvolvimento ou teste, eu não habilitaria o filtro PHP ou usava o código PHP que é passado para eval().

O filtro PHP foi removido do Drupal 8. Agora é um módulo de terceiros , não coberto pela política de aviso de segurança . Provavelmente, esse é um motivo a mais para não usá-lo em servidores de produção (se os motivos já apresentados não o convenceram).

Como uma solução alternativa para os vários problemas especificados acima - dificuldade de manutenção de código, controle de versão, localização de erros, você tem essa possibilidade "klugey":

Crie funções (nomeie-as com cuidado, de acordo com o que elas fazem) em algum arquivo sempre incluído - se você tiver um módulo personalizado que está escrevendo para o site, é um ótimo lugar para colocar essas funções. O php que você digita então é simplesmente: return my_specialfunc($somevar);- $somevaraqui sendo potencialmente o objeto do nó trabalhado, ou quaisquer outras variáveis ​​relevantes aqui.

Acho que ainda quero a flexibilidade, em alguns lugares, de chamar meu próprio código. Ao usar essa técnica, é fácil manter o código, pois é simplesmente uma questão de modificar a função no arquivo. A detecção de erros é fácil, pois a função será exibida em um backtrace.

Observe, no entanto, que isso não resolve os possíveis problemas de segurança. Estes são amplamente dependentes da segurança do núcleo Drupal. Em geral, o código contido no banco de dados geralmente é o ponto alto da segurança - as funcionalidades que usam o código contido no banco de dados tendem a ser muito mais propensas à exploração, e a segurança ao seu redor precisa ser muito rígida. No entanto, o Drupal em geral tem sido muito bom em manter a segurança desses problemas - eles surgiram e rapidamente foram corrigidos / resolvidos com os novos lançamentos.

Aqui está o motivo da vulnerabilidade de segurança para evitar conceder essa permissão aos seus usuários, se você não desejar que seus usuários não administradores modifiquem o banco de dados diretamente.

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

Hackeando as credenciais do Drupal db

Em vez de fazer algo assim return functionname($object), seria melhor usar o sistema de tokens / filtros na medida do possível. Existem módulos como o Insert View e o Embed Node que podem ajudar em circunstâncias comuns nas quais as pessoas desejam incorporar o PHP nos corpos dos nós ou blocos.

Você deve se preocupar com a portabilidade de seus dados. E se você migrar seus nós do drupal 7 para o drupal 8 e o texto do corpo de algum nó contiver <?php whatever_function_that_does_not_exist_anymore(); ?>?

Não pense no seu projeto dentro de 5 meses, mas dentro de 5 anos. Atualizações, boas práticas e portabilidade são aspectos importantes de qualquer bom projeto de TI na minha opinião.

Usar o menor número possível de módulos contribuídos também é um aspecto disso.