URL Hide Login

Bonjour graphandco,

Merci pour ce retour très précis : c’est exactement le cas limite qu’on ne voit qu’avec un setup headless réel.

Vous avez raison sur toute la ligne. Login Armor utilisait home_url() pour générer l’URL de login alors que WordPress core lui-même utilise site_url() dans sa fonction wp_login_url(). C’est un héritage du fork d’origine du module Hide Login, et ça casse silencieusement dès que siteurl ≠ home (multisite headless, WordPress dans un sous-dossier /wp/, reverse-proxy avec WP_HOME ≠ WP_SITEURL). Sur les installs standard les deux valeurs sont identiques donc personne ne s’en rend compte.

C’est corrigé en 2.1.9, publiée à l’instant sur WP.org. Tout le flux Hide Login bascule sur site_url() (URL login, redirections, password-reset cookie scope, lostpassword, register, logout, lockout page, prévisualisation Settings). Côté multisite Network Admin, les liens “Dashboard” utilisaient déjà get_site_url($blog_id, $slug), ce qui était correct, donc rien à toucher de ce côté.

J’ai aussi ajouté un filtre login_armor_login_url_base au cas où vous auriez encore un setup plus exotique (3e hostname behind reverse-proxy, plugin de subdomain mapping qui réécrit l’admin URL) :

add_filter( 'login_armor_login_url_base', function( $url, $path, $scheme, $slug ) {
    // $url contient site_url($path, $scheme) par défaut
    return 'https://votre-hostname-custom.com' . $path;
}, 10, 4 );

Mettez à jour depuis Extensions > Mises à jour et l’URL de login devrait pointer sur admin.monsupersite.com/<votre-slug>/ comme attendu. Je suis preneur d’un retour si quelque chose cloche.

Merci d’avoir signalé : c’est notre premier retour terrain sur du multisite headless avec Login Armor, et ça aurait pu rester silencieux longtemps.

Bonjour graphandco,
Bonne nouvelle, j’ai aussi shippé V2.1.10 entre temps — un fix cosmétique sur la page 404 servie quand un anonyme tape /wp-admin/ (le 404 affichait à tort le menu du site dupliqué + sticky header). Ça touchait votre cas aussi puisque vous êtes en redirect vers /wp-admin/.

Pour le 404 sur admin.monsupersite.com/wp-admin/ après login, j’ai investigué en reproduisant votre setup en local (siteurl admin.X.local, home X.local). Conclusion : le code Login Armor V2.1.9/V2.1.10 fonctionne correctement — quand le navigateur envoie ses cookies d’auth (wordpress_logged_in_* + wordpress_sec_*) sur admin.monsupersite.com/wp-admin/, Login Armor laisse passer la requête, WordPress charge l’admin normalement.

Le 404 que vous voyez signifie donc que vos cookies d’auth ne sont pas envoyés à admin.monsupersite.com par votre navigateur. C’est typique d’une config multisite headless où COOKIE_DOMAIN n’est pas défini avec le wildcard sous-domaine. Sans cette définition, WordPress crée le cookie scopé sur le hostname exact où vous vous êtes connecté, et il n’est plus envoyé sur les autres sous-domaines.

Solution à tester : ajoutez dans votre wp-config.php (avant la ligne /* That's all, stop editing! */) :

define( 'COOKIE_DOMAIN', '.monsupersite.com' ); // remplacez par votre domaine, le point initial est important

Le . initial autorise le cookie sur tous les sous-domaines (admin.monsupersite.com, monsupersite.com, et tout autre *.monsupersite.com). Reconnectez-vous via admin.monsupersite.com/<votre-slug>/ après ce changement, le redirect vers /wp-admin/ devrait passer.

Si ça ne suffit pas (par exemple si un plugin tiers force un autre COOKIE_DOMAIN), je peux aussi vous fournir un mu-plugin de debug qui dump l’état des cookies au moment de la requête sur /wp-admin/. Dites-moi.

Merci encore pour le retour, ça a directement déclenché V2.1.9 + V2.1.10 sur WP.org.

Bonjour graphandco,
Merci d’avoir confirmé que V2.1.9/V2.1.10 résolvent votre cas principal. Pour vos sous-sites mappés sur des domaines externes : de notre côté on s’arrête là sur Login Armor, pour la raison que vous avez identifiée vous-même : un cookie d’auth ne peut pas traverser deux domaines DNS distincts (monsupersite.com ≠ domaineexterne1.com). C’est une limite cookie HTTP, pas quelque chose qu’un plugin peut contourner sans monter un système SSO complet (avec tokens + redirects), ce qui sort du périmètre de Login Armor.

Deux pistes pour vous selon ce que vous voulez :

1. Auth séparée par domaine externe (le plus simple)

Chaque sous-site garde son propre flow login. Vos admins se connectent directement sur domaineexterne1.com/<slug-du-sous-site>/, le cookie est posé sur domaineexterne1.com, le redirect post-login va sur domaineexterne1.com/wp-admin/. Login Armor stocke le slug en blog_option (per-site) et V2.1.9+ génère l’URL de login depuis site_url() — donc si vos sous-sites ont leur siteurl correctement mappé sur le domaine externe (cas standard du domain mapping), ça fonctionne sans rien faire de plus.

Si pour une raison X vous voulez forcer un hostname différent de site_url() (par exemple siteurl reste sur le réseau d’origine mais vous voulez que la page de login soit servie sur le domaine externe), le filtre login_armor_login_url_base introduit en V2.1.9 permet de l’overrider per-site. Snippet générique à laisser ici pour quiconque tombe sur ce thread avec un cas similaire — à déposer dans wp-content/mu-plugins/la-multisite-login-domain.php :

<?php
/**
 * Plugin Name: Login Armor — Per-Site Login Domain Override
 * Description: Override Login Armor's login URL hostname per blog_id
 *              when site_url() doesn't match where you want the login
 *              page to be served (typical: multisite + external domain
 *              mapping with siteurl on a different host than the public one).
 */
if ( ! defined( 'ABSPATH' ) ) { exit; }

add_filter( 'login_armor_login_url_base', function ( $url, $path, $scheme, $slug ) {
    $custom_hosts = [
        // blog_id => hostname (avec scheme)
        2 => 'https://domaineexterne1.com',
        3 => 'https://domaineexterne2.com',
        // une ligne par sous-site à customiser
    ];
    $blog_id = get_current_blog_id();
    if ( isset( $custom_hosts[ $blog_id ] ) ) {
        return $custom_hosts[ $blog_id ] . $path;
    }
    return $url; // default site_url() pour les autres
}, 10, 4 );

2. SSO centralisé sur admin.monsupersite.com

Tous les admins se connectent au même endroit puis sont redirigés vers leur sous-site via tokens. Le plugin WP MU Domain Mapping (gratuit, mature) propose exactement ça avec son option “Login Mapping”. C’est la voie standard pour ce cas, hors périmètre Login Armor.

Votre retour a directement déclenché V2.1.9 + V2.1.10 sur WP.org, encore merci. Bonne route !

Merci infiniment pour ce retour, ça fait vraiment plaisir.

L’info sur les autres plugins qui gèrent les domaines externes est précieuse — c’est probablement effectivement un mécanisme de SSO style WP MU Domain Mapping (token signé en URL pour transiter d’un domaine à l’autre, qui se traduit en cookie auth de l’autre côté). On l’a noté dans notre backlog roadmap pour V2.2+, si la demande remonte d’autres utilisateurs en multisite domain-mapping on regardera comment l’intégrer proprement dans Login Armor sans casser le périmètre actuel “Hide / Block / Watch”.

Et merci pour le bouche-à-oreille, c’est exactement ça qui fait vivre les plugins gratuits et indépendants. Bonne continuation sur votre projet multisite, et n’hésitez pas à revenir sur le forum si vous croisez d’autres edge cases.

Bravo pour le diagnostic ! Effectivement, pas de .htaccess sur Docker + Caddy = pas de RewriteRule WordPress = boucle 302 sur /wp-admin/ indépendamment de Login Armor. Confirmé par votre test avec LA désactivé.

Pour info, V2.1.11 a quand même été publiée entre temps (HideLogin::build_login_url() host-aware + dual-base matching dans intercept_request) => c’est une amélioration robuste pour les setups multisite + domain mapping en général, même si dans votre cas spécifique c’était la config web server qui posait souci. Donc rien à perdre à mettre à jour, et ça vous protège contre des cas similaires futurs.

Merci d’avoir creusé jusqu’à la cause root et de l’avoir partagé ici — votre stack Docker + Caddy n’est pas la plus courante côté WordPress, et votre retour aidera d’autres utilisateurs qui tombent sur le même symptôme. Bonne continuation !