Pourquoi un employé non SuperAdmin reçoit-il une erreur de jeton (token) invalide en se connectant au back-office PrestaShop ?

Un responsable de boutique PrestaShop signale qu'un nouvel employé, ou un collaborateur dont le profil vient d'être modifié, obtient un message d'erreur de type « jeton invalide » (invalid token) dès qu'il tente de se connecter ou de naviguer dans le back-office. Le compte SuperAdmin, lui, fonctionne sans problème. Ce symptôme est fréquent et provient presque toujours d'une désynchronisation entre le cache de permissions, les cookies de session et la configuration réelle du profil employé.

Comprendre le rôle du jeton dans PrestaShop

Chaque action dans le back-office PrestaShop (accès à un onglet, soumission d'un formulaire) est protégée par un jeton de sécurité (token), généré à partir de la clé de cryptographie de la boutique (COOKIE_KEY), de l'identifiant de l'employé et du contrôleur ciblé. Ce mécanisme empêche les attaques de type CSRF (falsification de requête inter-site). Si le token calculé par le navigateur ne correspond pas à celui attendu par le serveur, l'accès est refusé, même pour un utilisateur légitime.

Pour un profil SuperAdmin, les droits sont quasi illimités et les vérifications sont moins susceptibles de buter sur une restriction. Pour un profil personnalisé (ex. gestionnaire catalogue, service client), le moindre écart entre les droits enregistrés en base et le cache utilisé par PrestaShop déclenche l'erreur.

Les causes les plus fréquentes

• Cache des permissions obsolète : après une modification de profil (ajout d'un onglet, changement de droits), PrestaShop doit régénérer le cache de permissions ; s'il ne le fait pas automatiquement (problème de droits d'écriture sur le dossier /var/cache), l'ancien cache reste actif.
• Changement récent d'URL d'administration : si le dossier admin a été renommé sans vider le cache, les jetons générés avant le changement deviennent incohérents.
• Cookie employé corrompu ou expiré : un cookie de session ancien, conservé dans le navigateur, peut contenir des informations obsolètes sur le profil.
• Modification de la clé de cryptographie (COOKIE_KEY dans config/settings.inc.php) : si cette clé a été régénérée (migration, restauration de sauvegarde), tous les tokens précédemment émis deviennent invalides.
• Profil employé incomplet : un profil créé sans association correcte aux onglets (table ps_access) peut générer des incohérences de calcul de token sur certains contrôleurs.

Étapes de diagnostic

1. Reproduire l'erreur avec un autre navigateur ou en navigation privée pour écarter un problème de cookie local.
2. Vérifier les droits du profil dans Paramètres avancés > Équipe > Profils, puis contrôler onglet par onglet que les permissions (afficher, modifier, supprimer) sont correctement cochées pour les contrôleurs concernés.
3. Vider le cache via Paramètres avancés > Performances, ou manuellement en supprimant le contenu des dossiers /var/cache/dev et /var/cache/prod (sans toucher aux fichiers de configuration).
4. Contrôler les droits d'écriture serveur sur /var/cache et /app/cache (environ 755 ou 775 selon la configuration), car un dossier non inscriptible empêche la régénération automatique du cache.
5. Déconnecter puis reconnecter l'employé après ces opérations, pour forcer la génération d'un nouveau cookie et de nouveaux tokens.

Solutions correctives

Dans la majorité des cas, vider le cache applicatif après une modification de profil résout le problème immédiatement. Si l'erreur persiste, il faut vérifier dans la base de données (table ps_employee et ps_access) que l'employé est bien rattaché au bon profil et que les droits associés existent réellement pour les onglets utilisés.

Si le problème est apparu après une restauration de sauvegarde ou une migration, comparez la valeur de COOKIE_KEY dans config/settings.inc.php entre l'environnement source et l'environnement cible : une différence invalide tous les jetons émis avant la bascule, et impose une reconnexion complète de tous les employés.

Points de vigilance pour éviter la récidive

• Après toute modification de profil ou d'onglet, videz systématiquement le cache avant de tester la connexion de l'employé concerné.
• Évitez de modifier manuellement la table ps_access sans passer par l'interface, car cela peut créer des incohérences invisibles côté cache.
• Documentez les changements de droits dans un registre interne, utile en cas de diagnostic ultérieur par un prestataire externe.
• Sur les boutiques multi-environnements (préproduction/production), ne copiez jamais la configuration sans vérifier la cohérence de COOKIE_KEY.

Si l'erreur persiste malgré ces vérifications, ou si plusieurs profils sont concernés simultanément, il peut s'agir d'un conflit plus profond lié à un module tiers interférant avec la gestion des sessions. Performeer PrestaShop met en relation les dirigeants de boutique avec des prestataires qualifiés pour diagnostiquer ce type d'incident, sans engagement et en toute neutralité.