web-dev-qa-db-fra.com

Cette solution pour les caches contre les cookies va-t-elle m'attirer des ennuis?

J'ai mis au point une solution provisoire pour un problème non commun, mais loin d'être sans précédent, de l'interaction de solutions de mise en cache WP populaires avec des cookies, en l'occurrence le commentaire standard WP biscuits. Ma solution porte également sur l'exception "utilisateurs connus", rarement définie, de la fourniture de fichiers en cache. Que ce soit utilisable ou non, je pense que l'expliquer et éventuellement comprendre pourquoi c'est une mauvaise idée pourrait être généralement instructif.

J'ai testé ma méthode avec WP Super Cache, W3 Total Cache et Comet Cache. Celui que j'ai décomposé en détail lors de l'étude de ce problème était WP Super Cache ("WPSC" ci-après), je vais donc l'utiliser comme principal exemple.

CONTEXTE

Lorsqu'un fil de commentaires standard WP est défini pour permettre aux visiteurs de commenter, les cookies de commentaires sont configurés pour tout commentateur qui n'est pas un utilisateur enregistré et connecté. Ses privilèges de commentaire sont soumis à des vérifications supplémentaires. Dans ce que je crois être la configuration la plus courante, un intervenant doit uniquement fournir un nom et une adresse électronique. Ceux-ci sont stockés dans deux cookies de navigateur, généralement comment_author_ . COOKIEHASH et comment_author_email_ . COOKIEHASH. COOKIEHASHest défini en fonction des options de l'utilisateur.

S'il est configuré pour fournir des fichiers nouvellement générés à des "utilisateurs connus", le WPSC détermine si un fichier mis en cache doit être ou non servi sur la base de plusieurs vérifications: les utilisateurs connectés obtiennent de nouveaux fichiers, ainsi que les visiteurs "qui peut commenter". Ces derniers sont principalement identifiés par la présence dans leurs navigateurs de cookies comment_author_ qui ne sont pas spécifiquement identifiés pour l'utilisateur particulier par le COOKIEHASH(généralement mais pas toujours une version codée MD5 du "siteurl" enregistrée dans les options de site).

Ce qui semble être la partie clé du code WPSC, de wp-cache-phase1.php LL371-383, utilise un motif RegEx pour obtenir une chaîne, en passant en revue les cookies:

$regex = "/^wp-postpass|^comment_author_";
if ( defined( 'LOGGED_IN_COOKIE' ) )
    $regex .= "|^" . preg_quote( constant( 'LOGGED_IN_COOKIE' ) );
else
    $regex .= "|^wordpress_logged_in_";
$regex .= "/";
while ($key = key($_COOKIE)) {
    if ( preg_match( $regex, $key ) ) {
        wp_cache_debug( "wp_cache_get_cookies_values: $regex Cookie detected: $key", 5 );
        $string .= $_COOKIE[ $key ] . ",";
    }
    next($_COOKIE);
}

Maintenant, si je travaillais strictement en PHP, je pourrais reproduire ou raccorder des fonctions de base WP et obtenir le code comment_author_ . COOKIEHASH normal défini par le modèle de commentaire, mais je travaille avec jQuery à l'aide du plug-in cookie jQuery. -dans. Toutefois, comme vous pouvez le voir si vous consultez RegEx, la fonction WPSC ne se soucie pas de COOKIEHASHname__: Elle est satisfaite si elle rencontre comment_author_.

Ma solution provisoire

$.cookie( 'comment_author_proxyhash', 'proxy_author', { path: '/' } );

Pour ceux qui ne connaissent pas jQuery Cookie: La procédure ci-dessus définit un cookie de session simple avec clé = comment_author_proxyhash et valeur = proxy_author, valable pour l'ensemble du site. (En outre, pour ceux qui utilisent jQuery Cookie et WP, en plus de pré-remplacer le familier jQuery $ par le WP jQueryname__, j'ai également déjà défini $.cookie.raw = true;.)

J'ai ajouté la ligne à mon script jQuery, et voila! , WPSC, W3 Total Cache et Comet Cache agissent tous comme je le souhaite. Après avoir utilisé le script et rechargé, je reçois de nouvelles pages. S'il m'est arrivé de placer un vrai commentaire, les cookies normaux comment_author_ et comment_author_email_ sont définis et il ne semble pas y avoir de problème de coexistence.

Peut-être un défaut serait-il que le cookie "proxyhash" voyagera avec l'utilisateur tant qu'il gardera la session ouverte, mais cela ne me semble pas être un problème majeur - ni même un avertissement. Je n'ai certainement jamais entendu parler de quelqu'un se plaindre d'une telle chose se produisant avec l'un des cookies réguliers.

Mais peut-être qu'il me manque quelque chose et sur le point de découvrir beaucoup de choses à mon malheur, si potentiellement à mon édification aussi. Ou peut-être existe-t-il un moyen relativement simple, selon les meilleures pratiques, de reproduire le COOKIEHASHdans jQuery, en couvrant également les cas d'utilisation alternatifs ... ou d'obtenir le même effet final par d'autres moyens - d'autres moyens de tromper les plug-ins de mise en cache pour traiter visiteur comme commentateur ...

Sinon, y a-t-il une bonne raison de NE PAS pousser ceci ou quelque chose de proche vers l'univers dans un plug-in?

jquerycachecookiesplugin-w3-total-cacheplugin-wp-supercache
23
CK MacLeod

Votre solution avec le cookie comment_author_proxyhash fonctionnera évidemment sur le plan technique: tous les plugins de mise en cache que je connais n’analysent pas la valeur de hachage et arrêtent simplement la diffusion du contenu mis en cache sur la base du cookie présent de comment_author_ *.

Le problème ici est que les sites Web ont vraiment besoin de la fonctionnalité de mise en cache des pages. Souvent, la mise en cache des pages est configurée avec précision, car les performances WordPress nues ne suffisent pas et peuvent même faire planter le serveur aux heures de pointe. Cela dépend de la nature du contenu du site Web, mais les propriétaires de sites ne sont parfois tout simplement pas en mesure de payer le matériel nécessaire pour tout gérer via le code PHP/WP. Autrement dit, autant que possible, le trafic doit être servi à partir du cache de pages. De pratique, je peux dire que nous devons souvent identifier et désactiver les plugins faisant des exceptions de cache.

Bien sûr, ce n'est pas toujours possible, mais essayez de travailler avec une page en cache chaque fois que cela est possible. Par exemple, vous pouvez masquer les balises div avec les commentaires que vous souhaitez ignorer via javascript, ou le blocage de commentaires entiers ajax-ify.

Dans tous les cas, vous n'avez pas besoin de marquer le visiteur en tant que commentateur, mais d'arrêter la mise en cache pour des raisons de logique personnalisée. Il est donc préférable d'utiliser un cookie unique et d'en faire un signal d'exception de cache. W3 Total Cache a l'option "Refuser les cookies" pour cela, mais pas les autres plugins de votre liste, vous aurez donc besoin d'un hack comme celui que vous avez suggéré.

1
WowPress.host