OFFRE DE LANCEMENT — LIMITÉE Das Nest Lifetime 499 € 149 € Profiter de l’offre →
KakapoWP KakapoWP
Centre d'aide/Security/Déplacer l'adresse de connexion : configurer, vérifier, revenir en arrière

Déplacer l'adresse de connexion : configurer, vérifier, revenir en arrière

S'applique à : Kakapo Security· 4 min de lecture

Ce qui doit être en place au préalable

Par défaut, la fonction est désactivée et elle ne s'active jamais d'elle-même. Trois choses empêchent complètement le déplacement — l'interrupteur reste alors bloqué et en indique la raison : (1) le frein d'urgence define( 'KWPSEC_LOGIN_SLUG_OFF', true ); figure dans le wp-config.php. (2) L'installation est un réseau Multisite ; là, tous les sites partagent une même connexion, le déplacement devrait donc se faire à l'échelle du réseau. (3) Les permaliens sont réglés sur « Simple ». Dans ce cas, un chemin comme /gartentor n'atteint aucun PHP, le serveur web répond avant avec un 404. Passe à une autre structure sous Réglages › Permaliens avant de continuer.

Choisir un chemin

Sont autorisés 3 à 40 caractères : minuscules, chiffres, tiret et tiret bas. Pas de barres obliques, pas de trémas, pas de point ; les majuscules sont converties en minuscules. Quatre contrôles s'exécutent à l'enregistrement : les noms figurant sur les listes de robots habituelles (login, wp-login, admin, wp-admin, anmelden, dashboard et similaires) sont refusés, car ils seraient retrouvés en quelques minutes. S'il existe déjà dans l'installation WordPress un fichier ou un répertoire portant ce nom, la saisie est refusée — le serveur web le livrerait avant que PHP soit sollicité. Les routes réservées comme wp-json, feed, author, category, sitemap ou favicon sont bloquées. Et si un article ou une page se trouve déjà sous ce chemin, la saisie est refusée, car cet article ne serait plus accessible ensuite. Un chemin enregistré n'est pas encore en vigueur — il ne prend effet que lorsque vous activez en plus le déplacement.

Activer : ce qui se passe alors automatiquement

Quand vous basculez l'interrupteur, le réglage est enregistré, puis le serveur effectue deux véritables requêtes HTTP contre sa propre installation : une vers la nouvelle adresse, une vers l'ancienne. Chaque appel dispose d'un délai de 8 secondes, ne suit aucune redirection et n'envoie aucun cookie. Pour prouver que c'est bien la page de connexion qui a répondu, le texte renvoyé est examiné à la recherche de id="loginform" et name="log". Si la nouvelle adresse répond avec un HTTP 404 et sans formulaire de connexion, la modification est immédiatement annulée et l'état précédent rétabli — dans ce cas, c'est le plus souvent la ligne try_files qui manque sous nginx, et le .htaccess sous Apache. Si le contrôle aboutit, le plugin envoie la nouvelle adresse dans un e-mail en texte brut à l'adresse de notification enregistrée (à défaut à l'e-mail de l'administration) ; l'e-mail contient aussi la ligne du frein d'urgence pour le wp-config.php. Le retour indique sans fard si wp_mail() a accepté le message — si ce n'est pas le cas, notez l'adresse dès maintenant. Une entrée est également écrite dans le journal d'activité.

Ce qui change à l'usage

Sous le nouveau chemin, le fichier d'origine wp-login.php est inclus, et non reconstitué — les mises à jour de sécurité de WordPress y agissent immédiatement. Pour les personnes déconnectées, /wp-login.php se comporte comme n'importe quelle adresse qui n'existe pas : la requête est réécrite vers un chemin inoccupé et rendue tout à fait normalement par le thème sous forme de 404, sans message d'erreur propre — un message propre serait justement l'indice que quelque chose est caché ici. Qui est connecté passe toujours ; c'est voulu. Si une personne déconnectée appelle /wp-admin/, elle est renvoyée en 302 vers la page d'accueil et non vers la connexion, sinon la nouvelle adresse figurerait dans l'en-tête Location. admin-ajax.php, admin-post.php, load-styles.php et load-scripts.php restent accessibles, pour que les formulaires de contact, les paniers et les avis continuent de fonctionner. Toutes les adresses que WordPress génère via site_url(), network_site_url() ou wp_redirect() — wp_login_url(), wp_logout_url(), wp_lostpassword_url(), l'attribut action du formulaire — pointent automatiquement vers le nouveau chemin.

Si vous vous excluez vous-même ou que quelque chose coince

Première voie : tant que votre navigateur contient un cookie de connexion valide, vous atteignez /wp-login.php et /wp-admin/ comme avant. Deuxième voie : l'adresse figure dans l'e-mail envoyé lors du changement. Troisième voie : inscrivez define( 'KWPSEC_LOGIN_SLUG_OFF', true ); dans le wp-config.php — wp-login.php redevient alors immédiatement valable, et l'interrupteur reste bloqué jusqu'à ce que vous supprimiez cette ligne. Dans la zone d'administration, il y a en outre deux boutons : l'un relance l'appel de vérification et affiche le code HTTP, le temps de réponse et le statut de l'ancienne adresse, l'autre renvoie l'e-mail d'accès. Si l'appel de vérification signale une erreur réseau au lieu d'un code HTTP, c'est le plus souvent que le loopback est bloqué chez l'hébergeur — cela ne veut pas dire que l'adresse ne fonctionne pas ; appelez-la une fois vous-même. Si un lien d'un autre plugin continue de pointer vers wp-login.php, c'est qu'il y est codé en dur et ne passe pas par site_url() ; seul ce qui passe par ces filtres peut être réécrit. Le retour en arrière est possible à tout moment via le même interrupteur.

Cet article vous a-t-il été utile ?