web-dev-qa-db-fra.com

Sanitizing `wp_editor ();` Valeurs pour la base de données, l'édition et l'affichage

J'utilise des instances personnalisées de wp_editor(); pour permettre l'édition en texte enrichi de Post Meta associé à un objet Post.

J'aimerais effectuer une grande partie de la même désinfection que celle utilisée avec post_content pour les valeurs de ces champs.

Voici ce que je suis venu avec:

Faites-moi savoir s'il s'agit d'une approche acceptable, ou si je devrais en faire plus dans l'une ou l'autre de ces trois étapes, ou s'il existe un moyen plus simple ou meilleur.

Sur save_post: 

$value = wp_filter_post_kses( sanitize_post_field( 'post_content', $value, 0, 'db' ) );

Valeur de passage à wp_editor();: 

$value = wp_unslash( sanitize_post_field( 'post_content', $value, 0, 'edit' ) );

Valeur de sortie sur le frontend: 

$value = wp_unslash( sanitize_post_field( 'post_content', $value, 0, 'display' ) );
postscustom-fielddatabasepost-metasanitization
3
Michael Ecklund

wp_kses à la rescousse!

Mon éditeur contient tout ce qu'un message peut contenir

Passez le résultat par wp_kses_post en entrant et en sortant, et tout devrait être bon.

Souvenez-vous que ceci supprimera tout élément ajouté par le filtre the_content. Par conséquent, pour conserver les oembeds et les shortcodes, utilisez ceci:

echo apply_filters( 'the_content', wp_kses_post( $content ) );

Vous voudrez peut-être aussi esc_textarea pour la sortie du formulaire si vous utilisez directement les balises <textarea>

Mon éditeur contient du texte, mais pas de balisage

En sortie, esc_html est votre ami. Utilisez cette option pour les situations où vous avez une zone de texte qui ne contiendra jamais de balisage. Lors de la saisie, essayez wp_strip_all_tags sur la saisie pour désinfecter. Les autres WP API s'assureront qu'aucune injection SQL n'a lieu

Mon éditeur contient des balises, mais un sous-ensemble limité

wp_kses à la rescousse, transmettez-le par wp_kses avec un deuxième paramètre, un tableau définissant les balises et attributs autorisés. Par exemple.:

$allowed = [
    'a' => [
        'href' => [],
        'title' => []
    ],
    'br' => [],
    'em' => [],
    'strong' => [],
];

echo wp_kses( $content, $allowed );

Méfiez-vous des surendenses. Si vous ajoutez des balises script et iframe, l'utilisation de wp_kses a-t-elle vraiment un sens?

wp_editor

wp_editor sort en interne, il ne peut pas être échappé, il est donc responsable de s'échapper lui-même. N'essayez pas de ne pas être utile en lui transmettant du contenu pré-échappé, cela risquerait d'entraîner une sortie mutilée et une double échappement (un excellent moyen de contourner le contenu mal formé).

La fonction qui en résulte a la responsabilité de s’échapper. Cela permet une fuite tardive. S'échapper plus tôt ou à plusieurs reprises est dangereux et introduit de nouveaux problèmes complexes, car vous ne savez plus avec certitude ce qui est échappé ou non.

1
Tom J Nowell

Je pense que vous êtes sur la bonne voie.

La fonction sanitize_post_field() appelle le content_save_pre hook qui, lorsque le contexte de la base de données lui est attribué, appellera également la fonction wp_filter_post_kses , de sorte qu'il n'est pas nécessaire de l'envelopper/de le rappeler.

Pour autant que je sache à ce stade, une fois que cela a été enregistré dans la base de données, il n'est pas nécessaire de supprimer quoi que ce soit pour l'affichage. Voici ce que j'ai qui est assez similaire à ce que vous aviez déjà:

Valeur d'économie 

update_post_meta( $post->ID, '_test', sanitize_post_field( 'post_content', $_POST['_test'], $post->ID, 'db' ) );

Valeur de passage 

$editor_content = get_post_meta( $post->ID, '_test', true );

wp_editor( $editor_content, 'editor_id_here', array(
    'textarea_name' => '_test',
) );

Affichage de la valeur 

$editor_content     = get_post_meta( $post->ID, '_test', true );
$display_content    = apply_filters( 'the_content', $display_content );
1
Howdy_McGee