Primeiro, leia sobre isso na API Drupal:
Então, check_plain()
codifica caracteres especiais com significado especial em HTML (como <
e &
) em entidades de texto sem formatação (ou seja, <
e &
respectivamente) que farão com que sejam renderizados literalmente (não interpretados como HTML) quando a sequência que for exibida como parte de uma página com Marcação HTML. A função filter_xss()
filtra uma sequência de caracteres HTML para evitar vulnerabilidades de script entre sites (XSS). Faz quatro coisas:
- Removendo caracteres e construções que podem enganar navegadores
- Garantir que todas as entidades HTML sejam bem formadas
- Garantir que todas as tags e atributos HTML sejam bem formados
- Certificando-se de que nenhuma tag HTML contenha URLs com um protocolo não permitido (por exemplo, javascript :)
Ambas as funções são usadas para limpar os dados dos usuários para garantir que qualquer injeção de usuário seja neutralizada antes que os dados sejam renderizados em seu site.
Você nunca passa a mesma corda pelos dois .
Se você usar check_plain()
, a sequência passada para a função deve ser usada como texto sem formatação (não HTML). Então filter_xss()
não é necessário, pois check_plain()
sempre tornará a string texto sem formatação.
Se você usar filter_xss()
, a string passada para a função deve ser HTML e check_plain()
a bagunçará.
Quando olho para o modelo que você usa como exemplo, parece-me que todos os três campos passados são print()
provenientes de conteúdo já higienizado e que não precisa de mais saneamento.
No entanto, se você criar seu próprio módulo que coleta as entradas do usuário sem passar por um filtro de texto "seguro", como "HTML filtrado" ou "Sem formatação", você deve usar essas funções para fins de limpeza.
filter_xss()
quando quiser XSS filtro de conteúdo potencialmente perigoso (ou seja, o conteúdo de um usuário não confiável), echeck_plain()
quando você quiser escapar HTML caracteres especiais de uma string