En résumé : un lien magique WordPress est un jeton long et aléatoire dont le hash HMAC-SHA256 — pas le jeton lui-même — est stocké dans ta base de données. Quiconque possède le lien entre sans mot de passe ; quiconque vole ta base de données obtient un hash impossible à retransformer en lien fonctionnel. C'est tout le modèle de sécurité en une phrase, et le reste de cet article explique pourquoi il tient la route.
Le problème avec l'ancienne façon de partager l'accès
Si tu as déjà donné à un client une URL de staging ou un mot de passe de page partagé, tu connais déjà les points faibles :
- Un mot de passe partagé est identique pour tout le monde. Impossible de savoir lequel de tes clients l'a partagé plus loin, et le révoquer éjecte tous les visiteurs en même temps — y compris le client en pleine relecture.
- Les URL de staging finissent indexées. Oublie un en-tête
noindex, et Google la trouve. "Non répertorié" n'est pas la même chose que "privé". - Aucun des deux n'expire de lui-même. Six mois plus tard, le lien qu'un ancien testeur de staging d'un client a enregistré dans son historique fonctionne toujours.
Rien de tout cela n'est un problème de force de mot de passe. Ce sont des problèmes d'identité — le système n'a aucun moyen de savoir qui utilise l'accès, seulement que l'accès était correct.
Ce qu'est réellement un lien magique
Un lien magique remplace "prouve que tu connais un secret que tout le monde connaît" par "prouve que tu détiens un jeton que personne d'autre n'a". Dans Erdo Client Preview, ce jeton est une chaîne aléatoire cryptographique — assez longue pour que la deviner soit infaisable en pratique — générée par personne, par usage, avec son propre label, sa propre expiration et son propre compteur d'utilisation.
Point crucial : le jeton brut ne t'est montré qu'une seule fois, à la création, dans l'URL que tu copies et envoies. Il n'est jamais écrit en base de données sous une forme qui pourrait être relue.
Pourquoi HMAC plutôt que simplement stocker le jeton
Voici la partie que la plupart des explications de "lien magique" passent sous silence. Stocker le jeton brut en base de données — même dans une colonne que personne ne regarde — crée le même risque que stocker des mots de passe en clair : une injection SQL ou une sauvegarde de base de données divulguée, et chaque lien actif devient utilisable par un attaquant.
La solution est HMAC (Hash-based Message Authentication Code), défini dans la RFC 2104 et intégré à la fonction hash_hmac() de PHP depuis PHP 5. HMAC combine un message (le jeton) avec une clé secrète (propre à ton installation WordPress) pour produire une signature — ici, HMAC-SHA256.
Ce que ça apporte :
- La base de données ne contient jamais que le hash. Une table
wp_optionsextraite ou une sauvegarde divulguée donne à un attaquant un condensé HMAC-SHA256 à sens unique, pas un lien utilisable. - Le hash ne peut pas être rejoué pour falsifier un autre jeton. Comme il faut la clé secrète pour calculer un HMAC correspondant, un attaquant ne peut ni remonter d'un hash à un jeton valide, ni soumettre un jeton arbitraire et le faire accepter sans connaître la clé.
- La vérification est un simple recalcul. Quand un visiteur ouvre un lien, le plugin recalcule le HMAC du jeton présenté et le compare au hash stocké. En cas de correspondance, le lien est authentique ; sinon, l'accès est refusé.
L'essentiel à retenir : HMAC transforme "le visiteur a-t-il présenté la bonne chaîne" en "le visiteur a-t-il présenté une chaîne que seul le serveur — et lui seul, avec sa clé secrète — a pu signer à l'origine". C'est une garantie nettement plus forte qu'une simple comparaison en clair.
Étape par étape : de la génération à l'accès
- Tu cliques sur "Générer un lien magique" dans l'admin WordPress. Le plugin génère un jeton aléatoire et calcule immédiatement son hash HMAC-SHA256 avec un secret propre à ton site.
- Seul le hash est enregistré en base de données, avec des métadonnées : un label, une expiration optionnelle, une redirection optionnelle et un compteur d'utilisation. Le jeton brut est intégré dans l'URL et n'est stocké nulle part ailleurs.
- Tu copies l'URL et l'envoies à qui a besoin d'y accéder — un client, une partie prenante, un relecteur.
- La personne ouvre le lien. Le plugin extrait le jeton de l'URL, recalcule son HMAC et le compare au hash stocké.
- En cas de correspondance, le plugin pose un cookie signé et HttpOnly, pour que la visiteuse puisse parcourir tout le site en direct sans recliquer sur le lien à chaque page. En cas de non-correspondance ou de lien expiré, elle ne voit que la page de maintenance ou "bientôt disponible".
- Tu révoques à tout moment — invalidant instantanément ce seul lien, sans toucher aux autres liens actifs.
Liens magiques face aux alternatives
| Approche | Accès par personne | Résiste à une fuite de BDD | Révocation individuelle | Effort de mise en place |
|---|---|---|---|---|
| Mot de passe de page partagé | Non — un seul mot de passe pour tous | Non — équivalent au clair, une réinitialisation bloque tout le monde | Non | Faible |
| URL de staging non répertoriée | Non — une seule URL pour tous | N/A — aucune authentification | Non (il faut changer l'URL) | Faible |
| Lien magique (vérifié par HMAC) | Oui — un jeton par personne | Oui — seul un hash est stocké | Oui — par lien | Faible (géré par le plugin) |
Si tu compares plutôt avec la protection par mot de passe intégrée à WordPress, on a détaillé cette comparaison dans Pages protégées par mot de passe vs liens de prévisualisation sécurisés.
Pourquoi c'est plus important qu'il n'y paraît pour le travail avec des clients
Les agences et freelances n'ont pas juste besoin d'un contrôle d'accès quelconque — ils doivent savoir qui a regardé quoi, quand ça cesse de fonctionner, et que retirer l'accès d'un client ne touche jamais celui d'un autre. Un identifiant par personne, révocable individuellement, qui expire individuellement, est le seul modèle qui offre les trois. Un mot de passe partagé n'en offre aucun.
C'est aussi pourquoi les liens magiques s'associent naturellement à des fonctionnalités comme les retours visiteurs et les annotations live au niveau des éléments : dès que tu sais quel jeton a ouvert le site, tu sais aussi de quel client provient telle annotation, sans lui demander de créer un compte au préalable.
Vois-le dans le code, pas seulement dans cet article
Erdo Client Preview est open source, donc rien de tout ça n'est à prendre sur parole. La génération des jetons et la vérification HMAC vivent dans le dépôt GitHub du plugin — lis le code source, ouvre une issue, ou propose une pull request si tu repères quelque chose à améliorer.
Pour conclure
Un lien magique n'est fiable qu'à hauteur de ce qui arrive au jeton après sa génération. Le stocker en clair transforme ta base de données en une liste d'identifiants utilisables ; le stocker sous forme de hash HMAC-SHA256 transforme une fuite en une liste de condensés inutiles sans la clé secrète qui les a produits. Un petit détail d'implémentation, avec un effet démesuré sur ce que te coûterait réellement une fuite de base de données dans le pire des cas.
Installe Erdo Client Preview gratuitement depuis WordPress.org et génère ton premier lien magique en moins d'une minute.