wpformation

Re-bonjour graphandco,
Petit complément après inspection du code de Defender (que je suspecte être l’autre plugin qui fonctionnait pour vous) : Defender ne fait pas de SSO cross-domain, il fait simplement du multisite-aware site_url() avec switch_to_blog(). C’est exactement ce que Login Armor V2.1.9 fait depuis ce matin.

Donc en pratique, votre setup multisite + domain mapping devrait marcher avec Login Armor 2.1.10 si vous accédez directement à domaineexterne1.com// au lieu de passer par admin.monsupersite.com. Chaque sous-site a son propre flow login indépendant sur son domaine, cookie posé sur le bon hostname, redirect /wp-admin sur ce hostname, no cross-domain issue.

N’hésitez pas à tester si c’est ce que vous cherchez. Bonne soirée.

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 !

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.

Hi martineva,
Thank you for your kind words, and congratulations on reaching 11/12 so quickly!

You’ve found a genuine bug : the GEO score check was looking for the organization data under the wrong internal key, so it could never detect it even when everything is properly configured.

I checked your site and I can confirm that everything is actually working perfectly on the front-end:

Your Organization schema (ProfessionalService) is properly generated with your name, address, phone, logo, sameAs, geo coordinates, etc.
Your Person schema for your author profile is there too
The Article schema correctly links author => publisher => organization
OGEEAT properly defers Open Graph to Yoast, no conflicts
So the only issue is the GEO score display : it shows 11/12 instead of 12/12. Your actual SEO structured data is already complete and correct.

I’ve already fixed it and it will be included in the next update (v2.2.1). In the meantime, you can safely ignore that one missing point : your organization is properly detected by search engines and AI.

Thanks for reporting this, first bug report and it’s a real one!