Conflit entre Heartbeat et Security Plugin : Dépannage de l'authentification de connexion et de 2FA

Dans le site WordPress, la pageAPI Heartbeat avec Modules de sécurité, pare-feu, mécanismes d'authentification de la connexion (y compris 2FA) Les conflits entre eux sont l'une des principales causes de décalage en arrière-plan, d'abandons fréquents, d'anomalies au niveau de l'éditeur et même d'impossibilité d'enregistrer le contenu.

De nombreux webmasters constateront qu'après avoir activé les plugins de sécurité ou renforcé la vérification de la connexion :

Le backend est fréquemment invité à se reconnecter
Elementor / Gutenberg Le rédacteur est souvent bloqué
Échec de la sauvegarde automatique ou messages répétés "connexion perdue".
Requête admin-ajax bloquée ou retardée

Ces problèmes ne sont pas accidentels, mais Le mécanisme d'interrogation en arrière-plan de Heartbeat crée un conflit structurel avec la politique de sécurité.

I. Que fait Heartbeat en arrière-plan ?

La nature du rythme cardiaque

Rythme cardiaque est utilisé par WordPress dans le backend Mécanisme d'interrogation AJAXLe principal moyen d'y parvenir est d'utiliser admin-ajax.php Envoyer périodiquement des demandes au serveur pour :

Maintien d'une session de connexion (session)
Articles de sauvegarde automatique
Empêcher la modification simultanée par plusieurs éditeurs
Synchronisation de l'état de l'arrière-plan

Par défaut :

Arrière-plan Fréquence des battements de cœur :15-60 secondes
Fréquence plus élevée en mode éditeur

Le rythme cardiaque est fortement lié à l'état de connexion.

C'est l'une des causes profondes du conflit :

Heartbeat request = authentification continue des utilisateurs connectés

Chaque demande de battement de cœur est essentiellement une demande :

Somme de contrôle des cookies
Contrôle de la validité de la session
Confirmation de l'autorité

Il se trouve que ces comportements se recoupent largement avec le champ d'action des plug-ins de sécurité, des WAF et des 2FA.

Deuxièmement, le plug-in de sécurité / pare-feu est comment "blesser accidentellement" Heartbeat ?

Logique de base du plugin de sécurité

La plupart des plugins de sécurité WordPress font ce qui suit :

Limiter les tentatives de connexion
Détecter la fréquence des demandes anormales
valider (une théorie) Cookie / Légitimité des jetons
Bloquer les comportements suspects dans admin-ajax

Du point de vue de la sécurité, c'est tout à fait raisonnable.

Mais voilà :

Pour les modules de sécurité, Heartbeat ressemble beaucoup à un trafic anormal.

Scénarios d'erreurs d'appréciation courantes

Scénario 1 : AJAX à haute fréquence est considéré comme une attaque

Rythme cardiaque toutes les 15 secondes
Éditeur + superposition d'enregistrement automatique
requête admin-ajax intensive

Résultats :

Identifié comme une tentative de violence
Restreint ou bloqué par des pare-feu
Le backend a commencé à échouer par intermittence

Scénario 2 : l'interrogation de cookies ou de jetons déclenche un échec de l'authentification

Certains plug-ins de sécurité le feront :

Rafraîchir périodiquement le jeton de connexion
Les anciens jetons sont directement invalidés

Lorsque Heartbeat utilise encore une ancienne session :

Retour 403 / 401
Forcer la déconnexion
Perte du statut d'éditeur

III. conflits typiques entre Heartbeat et 2FA (authentification secondaire)

La conception originale de 2FA

L'authentification à deux facteurs (2FA) est couramment utilisée :

Authentification secondaire lors de la connexion
Confirmation de l'opération à haut privilège
Revalidation forcée après l'expiration de la session

Le problème, cependant, est que de nombreux plug-ins 2FA ne font pas la différence de manière adéquate :

Comportement de connexion
Comportement de l'interrogation en arrière-plan lors de la connexion

Comment les conflits surviennent-ils ?

Logique erronée courante :

La demande de battement de cœur déclenche un jugement de "comportement sensible en arrière-plan".
Le plug-in de sécurité nécessite une revalidation 2FA
Mais Heartbeat ne peut pas faire d'authentification interactive

Le résultat :

Rythme cardiaque rejeté
L'éditeur perd sa session
La page indique "l'enregistrement a échoué" ou "vous devez vous reconnecter".

Symptômes observés en surface par l'utilisateur

Sortie soudaine de l'arrière-plan lors de l'édition d'une page
Impossible d'enregistrer après avoir saisi le contenu
Elementor affiche des erreurs de connexion
Sauts fréquents à la page de connexion

Ces questions sont souvent confondues :

Instabilité du serveur
Bug Elementor
Problèmes de navigateur

En fait, la cause première est l'existence de politiques de sécurité contradictoires.

Quatrièmement, pourquoi la réception est-elle complètement normale en ce qui concerne les visiteurs ?

Il s'agit d'un point de jugement très critique.

La raison est très simple :

Heartbeat fonctionne principalement sur wp-admin
Le Heartbeat n'est pas déclenché pour les utilisateurs du frontend
Les pare-feu sont généralement plus indulgents à l'égard des politiques de front office.

Vous verrez :

La vitesse d'accès au site web est normale
Seul le back-office est "de plus en plus difficile à utiliser".

V. Principes de règlement corrects (très important)

En cas de conflit entre Heartbeat et des plugins de sécurité, l'optionIl faut éviter deux extrêmes: :

❌ Arrêter directement Heartbeat
❌ Désactiver complètement les plug-ins de sécurité ou le 2FA

Le principe correct est le suivant :

Réduire la probabilité de conflit plutôt que de sacrifier la sécurité

VI. idées d'optimisation de la sécurité terrestre (sans affecter le front office)

Restrictions pour le backend uniquement Heartbeat

Idée maîtresse :

Ne pas désactiver Heartbeat
Réduction de la fréquence de fond
Ne fonctionne qu'avec wp-admin

Ceci fera l'affaire :

Réduire considérablement les requêtes AJAX
N'affecte pas la fonctionnalité principale de sauvegarde automatique
Réduire la probabilité d'être mal jugé par les plug-ins de sécurité

"Release" dans le plugin de sécurité admin-ajax.php

Il est recommandé de vérifier les éléments de réglage suivants :

admin-ajax Si le flux est limité
S'il est considéré comme un échec de connexion
Participation aux règles de protection contre la violence

meilleures pratiques: :

Assouplir les restrictions admin-ajax pour les utilisateurs connectés
Maintenir des politiques strictes pour les utilisateurs non connectés

Configuration de la "logique d'édition de la liste blanche du backend" pour 2FA

Si votre plugin 2FA le prend en charge :

Déclenché uniquement à la connexion 2FA
Pas de validation en double lors de l'édition

Veillez à l'activer.

Dans le cas contraire :

Le Heartbeat ne passe jamais l'authentification secondaire
L'expérience du backend continuera d'être instable

Stratégies agressives pour réduire l'expiration de l'état de connexion

Certains plugins de sécurité sont activés par défaut :

Expiration forcée de la session pendant une courte période de temps
L'opération en arrière-plan expirera au bout d'un certain temps

Recommandation :

Prolongation raisonnable de la durée de la session d'information
Veiller à ce que l'édition des pages longues ne soit pas interrompue

VII. Comment puis-je savoir si le problème a été résolu ?

Une fois l'optimisation terminée, vous devriez observer :

L'éditeur dorsal est nettement plus souple
La sauvegarde automatique n'échoue plus
Plus de déconnexions fréquentes
La requête Admin-ajax dans le navigateur Network panel renvoie systématiquement 200

Si c'est le cas, Heartbeat et le mécanisme de sécurité sont entrés dans un état de "coexistence pacifique".

VIII. en résumé : l'essentiel n'est pas un bogue, mais un conflit de stratégie

Résumez ce type de question en une phrase :

Le conflit de Heartbeat avec les plugins de sécurité / pare-feu / 2FA n'est pas un bug du système par nature, c'est Tension structurelle entre les sondages d'arrière-plan à haute fréquence et les politiques de sécurité agressives.

La clé de la solution n'est pas de savoir "qui fermer", mais plutôt de savoir :

Définition du rôle du backend de Heartbeat
Concevoir une politique de sécurité plus logique pour les utilisateurs connectés
Équilibrer la sécurité et la disponibilité

Contactez nous
Vous n'arrivez pas à lire le tutoriel ? Contactez-nous pour une réponse gratuite ! Aide gratuite pour les sites personnels et les sites de petites entreprises !	Service clientèle WeChat
① Tel : 020-2206-9892
② QQ咨询：1025174874
(iii) Courriel : info@361sale.com
④ Horaires de travail : du lundi au vendredi, de 9h30 à 18h30, jours fériés.