Pages CMS privées - Contenu réservé aux membres par groupe client, redirection automatique et liens masqués

Une seule grille, et vos pages privées le sont vraiment

Chaque page CMS de votre boutique apparaît sous forme de ligne. Chaque groupe client apparaît en colonne de cases à cocher. Cochez qui a le droit d'entrer, cliquez sur Enregistrer les règles d'accès, et c'est terminé. Pas de second écran, pas d'onglet de réglages à dénicher page par page, et rien à maintenir synchronisé.

La liste est consultable par recherche, chaque ligne porte un badge dynamique Tout le monde ou Groupes cochés uniquement pour voir l'état d'un coup d'oeil, et chaque page dispose d'un lien de prévisualisation.

Public tant que vous n'en décidez pas autrement

C'est le point qui compte vraiment quand vous ajouterez des pages dans plusieurs mois. Une page sans aucun groupe coché est publique. Les nouvelles pages CMS que vous créerez plus tard sont publiques automatiquement : elles n'ont pas besoin d'être déclarées auprès du module, et elles ne disparaîtront pas silencieusement de votre boutique parce que vous avez oublié une étape. Supprimez une page et sa règle devient simplement inutilisée. Il n'y a aucune table de synchronisation, et rien n'a jamais besoin d'être reconstruit.

Redirigez les visiteurs vers un endroit utile, pas vers un endroit déroutant

Choisissez l'URL sur laquelle doivent atterrir les personnes sans accès, et collez-la dans le champ. Laissez le champ vide et elles arrivent sur votre page d'accueil. La bonne pratique consiste à créer une courte page publique — "Ce contenu est réservé aux membres" — qui explique comment obtenir l'accès, et à y pointer la redirection.

Une boucle de redirection est impossible. Le module refuse une page restreinte comme cible de redirection au moment de l'enregistrement, vous avertit sur la page de configuration si une page déjà choisie devient restreinte par la suite, et bascule sur votre page d'accueil à l'exécution si le cas se produit malgré tout. Trois garde-fous distincts pour une seule erreur, parce que cette erreur-là ferme la boutique au nez de vos clients.

Ils se connectent, et arrivent exactement là où ils voulaient aller

Un visiteur clique sur une page privée, se fait rediriger, puis se connecte. La plupart des implémentations le déposent sur la page d'accueil et le laissent se débrouiller pour revenir. Celle-ci retient la page qu'il avait demandée et l'y emmène directement dès qu'il se connecte avec un compte autorisé.

Si le compte utilisé pour la connexion n'appartient pas à un groupe autorisé, le visiteur est envoyé sur votre page d'accueil plutôt que renvoyé vers une page qu'il ne peut toujours pas ouvrir. Et une connexion effectuée directement pendant le tunnel de commande est délibérément laissée intacte : personne n'est arraché à son paiement à cause d'une page CMS cliquée vingt minutes plus tôt.

Des liens masqués, calculés sur le serveur

Activez Masquer les liens vers les pages restreintes et les liens vers les pages qu'un visiteur ne peut pas ouvrir sont retirés des menus, des pieds de page et des listes de catégories CMS. Un lien de catégorie CMS ne disparaît que lorsque toutes les pages actives qu'elle contient sont privées pour ce visiteur : vous ne perdez donc pas une entrée de menu entière à cause d'une seule page restreinte.

Les identifiants restreints sont calculés côté serveur, visiteur par visiteur, puis injectés dans un petit bloc de code JavaScript sans aucune dépendance. Aucune requête n'est envoyée depuis le navigateur : ni une par lien, ni une seule tout court.

Soyons clairs sur ce que c'est, cependant : le masquage est cosmétique, et la redirection est la vraie protection. Un lien masqué existe toujours dans le HTML de la page. Cela n'a aucune importance, puisque la page vers laquelle il pointe reste inaccessible dans tous les cas.

L'accès est contrôlé sur la page, pas sur le lien

Un visiteur qui saisit l'URL directement, ou à qui un collègue l'a envoyée, est redirigé exactement comme tout le monde. Il en va de même pour les vues intégrées ?content_only=1, précisément le genre de porte dérobée qui piège les implémentations ne protégeant que le lien en front-office.

L'appartenance aux groupes fonctionne comme vous l'attendez

Un client connecté est considéré comme membre de tous les groupes auxquels il appartient — son groupe par défaut plus les groupes additionnels — lus directement dans ses affectations de groupes. Résultat : cela fonctionne correctement même sur les boutiques où l'option interne de gestion des groupes de PrestaShop est désactivée, un mode de défaillance discret que l'on rencontre ailleurs.

Déplacez un client dans un groupe autorisé depuis Clients → Groupes et toutes les pages privées de ce groupe s'ouvrent immédiatement pour lui. Il n'y a rien à réenregistrer dans le module.

Les visiteurs non connectés appartiennent au groupe Visiteur de PrestaShop. Vous pouvez le cocher pour garder une page restreinte accessible pour eux, même si c'est rarement ce que l'on recherche.

Conçu pour ne pas gêner vos autres modules

Aucune surcharge du coeur. La version 2 utilise trois hooks standard : actionDispatcherBefore décide de l'accès avant que la page ne soit dispatchée, actionFrontControllerSetMedia injecte le code de masquage des liens, et actionAuthentication gère le retour après connexion. Rien d'autre.

Cela compte plus qu'il n'y paraît. Les surcharges de CMS et de CmsController sont exactement les fichiers que les autres modules veulent eux aussi surcharger, et ils sont réputés pour rester sur le disque après une désinstallation. Ce module ne peut pas entrer en conflit avec eux, tout simplement parce qu'il n'y touche pas.

La version 2 a comblé deux véritables failles de sécurité

Cela mérite d'être dit sans détour, car il s'agit d'un module dont le rôle entier est le contrôle d'accès.

La version 1.x embarquait un point d'entrée AJAX d'administration accessible sans être connecté. Sa vérification de jeton comparait deux valeurs côté serveur qui étaient toujours égales entre elles : le contrôle passait donc pour tout le monde. N'importe qui connaissant l'URL pouvait lire — ou réécrire — vos règles d'accès. Un second point d'entrée public (classes/hidecmslink.php) acceptait un paramètre de jeton puis ne le vérifiait jamais, et la liste des pages exposait un paramètre de tri vulnérable à l'injection SQL.

La version 2 supprime tout cela. Toutes les actions de back-office s'exécutent désormais sur la page de configuration, derrière le jeton d'administration, et la mise à jour 2.0.0 supprime les anciens fichiers du disque au lieu de les y laisser traîner.

Ce que la version 2 a corrigé par ailleurs

L'ancienne fonction de masquage des liens envoyait une requête AJAX synchrone par lien et recouvrait la page d'une surcouche de chargement blanche — ce qui explique pourquoi la documentation 1.x déconseillait discrètement de l'activer. Il ne reste qu'un petit bloc de code et zéro requête.

Les nouvelles pages CMS étaient auparavant invisibles pour le module tant que quelqu'un n'avait pas ouvert la page de configuration, car une table de synchronisation devait se mettre à jour. La version 2 ne stocke que les pages restreintes : les nouvelles pages sont donc publiques et listées automatiquement.

Le lien de redirection était auparavant obligatoire, et le module insistait jusqu'à ce qu'il soit renseigné — avec une valeur par défaut en 1.x qui envoyait vos visiteurs sur prestashop.com. Il est désormais facultatif, validé, et un champ vide signifie simplement votre page d'accueil.

Enfin, jQuery UI 1.8 et ses plugins d'onglets étaient chargés dans votre back-office. Tout cela a disparu.

La mise à jour depuis la 1.x tient en une seule étape

Téléversez la version 2 par-dessus l'ancienne, ou utilisez le bouton de mise à jour du module. La mise à jour migre toutes les règles d'accès enregistrées ainsi que vos réglages vers le nouveau format, retire les surcharges du coeur de la boutique, supprime les fichiers 1.x y compris les deux points d'entrée vulnérables, et efface l'ancienne table cmspages. Il n'y a rien à reconfigurer : ouvrez simplement une fois le panneau Accès aux pages et vérifiez que vos règles sont bien arrivées.

La version 2.0.2 a corrigé un défaut de mise à jour qui mérite d'être nommé clairement : les étapes 2.0.0 et 2.0.1 conditionnaient toutes deux leur succès au fait que les appels registerHook() renvoient true. Une défaillance passagère — ou un hook déjà enregistré par une tentative précédente incomplète — marquait donc l'étape entière comme échouée et PrestaShop désactivait le module. Les hooks sont désormais enregistrés de manière idempotente et chaque étape rapporte un succès.

Compatibilité et multiboutique

PrestaShop 1.7, 8 et 9, en huit langues : allemand, anglais, espagnol, français, italien, néerlandais, polonais et turc.

En multiboutique, les règles d'accès sont globales : une page CMS partagée par plusieurs boutiques porte la même règle partout. Le panneau Accès aux pages liste les pages de la boutique dans laquelle vous travaillez actuellement, ou toutes les pages dans le contexte Toutes les boutiques, et l'enregistrement ne réécrit que les règles des pages qu'il a listées.

La désinstallation supprime les règles d'accès et les réglages du module. Vos pages CMS restent intactes : elles redeviennent simplement toutes publiques.

Questions fréquentes

Comment rendre une page privée ?

Cochez au moins un groupe client sur la ligne de cette page dans la grille Accès aux pages, puis enregistrez. Toute page sans groupe coché est publique, ce qui est également le comportement par défaut de chaque page que vous créerez ensuite.

Où atterrissent les visiteurs sans accès ?

Sur l'URL que vous avez définie dans les réglages, ou sur votre page d'accueil si vous laissez ce champ vide. Une courte page publique expliquant comment obtenir l'accès reste la meilleure option.

Un visiteur peut-il rester bloqué dans une boucle de redirection ?

Non. Le module refuse une page restreinte comme cible de redirection au moment de l'enregistrement, vous avertit si une page déjà choisie devient restreinte par la suite, et bascule de toute façon sur votre page d'accueil à l'exécution.

Que se passe-t-il si quelqu'un possède l'URL directe ?

Il est redirigé. L'accès est contrôlé sur la page elle-même plutôt que sur les liens qui pointent vers elle, et cela inclut les vues intégrées ?content_only=1.

Le masquage des liens protège-t-il réellement les pages ?

Non, et le module ne prétend pas le contraire. Le masquage est cosmétique : un lien masqué figure toujours dans le HTML. La redirection est la vraie protection, et elle est toujours active, que vous activiez le masquage ou non.

Un client a rejoint le bon groupe. Dois-je réenregistrer quelque chose ?

Non. Déplacez-le dans un groupe autorisé depuis Clients → Groupes et toutes les pages de ce groupe s'ouvrent immédiatement pour lui.

Le module surcharge-t-il les fichiers du coeur de PrestaShop ?

Non. Trois hooks standard et rien d'autre : il n'entrera donc pas en conflit avec les modules qui surchargent CMS ou CmsController, et il survit aux mises à jour de PrestaShop. Les surcharges de la 1.x sont retirées de votre boutique pendant la mise à jour.

Je passe de la version 1.x — vais-je perdre mes règles ?

Non. La mise à jour migre toutes les règles d'accès et vos réglages, retire les anciennes surcharges ainsi que les deux points d'entrée vulnérables de la 1.x, et efface la table obsolète. Ouvrez ensuite une fois le panneau Accès aux pages pour vérifier.