web-dev-qa-db-fra.com

Pourquoi ne peut-on pas équilibrer la charge de /wp-login.php?

J'ai vu plusieurs questions postées, mais elles ont soit réussi cet élément spécifique, soit laissées sans réponse.

En gros, j’ai établi un équilibre de charge entre deux instances du même site Web wordpress avec nginx à l’avant. Afin de me connecter avec succès, je dois épingler toutes les demandes de /wp-admin ou /wp-login.php sur un serveur particulier. Peu importe le serveur, tant que toutes les demandes sont adressées au même serveur.

Au début, je pensais qu'un serveur sauvegardait les données de session, mais j'ai regroupé mes sessions PHP uniquement pour le trouver, sans rien enregistrer. J'ai vérifié les cookies, mais aucun élément sensible au serveur n'y apparaît (uniquement le cookie de test WP qui a une valeur statique). J'ai surveillé en permanence le système de fichiers pour voir si un fichier était peut-être créé sur l'un des serveurs d'applications principaux, mais en vain. J'ai même vérifié le formulaire de connexion qui semble à peu près aussi simple que possible.

Je n'ai littéralement aucune idée de la raison pour laquelle WP voudrait même savoir quel serveur a réellement reçu la demande POST.

Je peux vous fournir la configuration nginx si vous voulez, mais c'est assez simple et je ne veux pas encombrer ce post.

performancewp-login-formnginx
1
Bratchley

Quelques points à vérifier:

  • Passez en revue wp_salt . Assurez-vous que tous les serveurs Web s'exécutent sur le même ensemble de sels dans le fichier wp-config.php. Idéalement, ceux-ci devraient être reflétés à partir d'un seul endroit.

  • Passez en revue is_ssl() et assurez-vous que cette fonction détecte correctement le protocole SSL sur tous vos serveurs Web. J'ai vu cette petite fonction causer beaucoup de maux de tête lorsque l'équilibreur de charge établit une connexion interne sur le port 80 au serveur Web. Si is_ssl() ne le détecte pas (en raison de l'équilibrage de la charge), cela peut être à l'origine de ce problème. c'est-à-dire modifications possibles du protocole de cookie.

Une solution rapide consiste à vérifier le protocole transféré dans wp-config.php

if ( ! empty( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
        && strcasecmp( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) === 0 ) {
    $_SERVER['HTTPS'] = 'on'; // Convince WordPress.
}

  • Examinez la variable d'environnement $_SERVER['REMOTE_ADDR'] et assurez-vous qu'elle est remplie de la même manière sur tous les serveurs Web. Il existe de nombreux plugins pour WordPress qui utiliseront cela, sans envisager un scénario à charge équilibrée.

    Le moyen le plus simple de vérifier consiste à vider la <?php phpinfo(); sur quelques serveurs Web et à vérifier s’ils le configurent correctement. Ou est-ce que l'adresse IP réelle se retrouve dans HTTP_X_FORWARDED_FOR, HTTP_CLIENT_IP ou autre chose? En bref, évitez les plugins déroutants en corrigeant REMOTE_ADDR.

  • Assurez-vous que l'heure du système est synchronisée sur tous les serveurs Web.

  • Examinez de plus près les plugins ayant pour objectif de prévenir les attaques par force brute, car ils sont plus susceptibles de faire une validation stricte. par exemple, en testant l'agent utilisateur, l'adresse IP, les modifications d'adresse IP, etc.

Si le problème persiste, publiez une liste des plug-ins actifs que vous utilisez et de la configuration Nginx que vous avez mentionnée. Il serait bon d’examiner les paramètres FastCGI, ainsi que toute configuration de proxy que vous pourriez avoir ou non.

2
jaswrks