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


96

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?


1
Como sempre, depende da situação! Se você precisar apenas de um bloco básico $ de impressão na parte inferior da página Views em um 'rodapé de visualizações', pode ser ideal fazê-lo através da GUI em comparação com a gravação de um arquivo tpl inteiro apenas para esse fim. Obviamente, isso também depende do papel do site e de outros fatores: prazo apertado? Site da comunidade de usuários? Ou apenas site informativo? É vital para as operações comerciais? etc ... depende.
Patoshi

Respostas:


129

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 :)


3
Lista agradável :) espero venha a ser um recurso para os outros
Laxman13

3
@ Laxman13: "para os outros" ... e para você também! : D @Berdir: +1, aspectos muito bons. A propósito, você não precisa escrever o código inteiro em um campo de texto, pois também pode incluir um arquivo lá. Por exemplo, você pode colocar apenas uma linha no campo de texto: require_once $_SERVER['DOCUMENT_ROOT'].'/sites/all/themes/myTheme/php/stuff.php';e escrever o restante do código no seu editor de IDE / texto. Às vezes, não é um trabalho fácil ou levaria muito tempo para criar um módulo próprio, mesmo como um bom desenvolvedor de PHP. Um pequeno exemplo: Ações Condicionais do Ubercart. Mas é verdade que não é bom manter nosso código em db.
Sk8erPeter

Quero dizer, por exemplo, o módulo UC Condicional Actions possui uma interface gráfica muito boa, que economiza muito tempo ao escrever nossos próprios códigos longos. Você pode criar uma ação realmente complexa em minutos com o método "next-next-finish" em uma GUI. Mas talvez você queira estender a funcionalidade com alguns de seus próprios códigos - em muitos casos, simplesmente não vale a pena desenvolver um módulo para esse fim.
Sk8erPeter

1
+1000 - Eu já vi tantos projetos queimados em praticamente todos os pontos desta lista. Houve apenas uma vez em toda a minha vida que usar o módulo PHP era a única maneira de fazer algo de maneira sã, e isso era apenas devido a um problema no D6 que foi corrigido no D7.
geerlingguy

Obrigado pelos seus detalhes, responda a esta pergunta. Eu encontrei uma situação enquanto trabalhava no Drupal, que quando precisamos adicionar um link no 'editor de texto', precisamos usar o código php no 'filtro de texto', caso contrário não funcionará conforme o esperado.
Jayendra Kainthola

17

É 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,


1
Bem, se a configuração do bloco foi exportada para o código com módulos de recursos, não é um problema colocar trechos de php sob controle de versão.
Ya.teck

14

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).


11

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.


11

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


7

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.


0

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.