Connexion clients impossible après mise à jour PrestaShop : diagnostic et solutions

Introduction

Après une mise à jour ou une migration PrestaShop, l'un des problèmes les plus fréquents — et les plus stressants — est l'impossibilité pour les clients de se connecter à leur compte. Le formulaire de connexion rejette systématiquement les identifiants, alors que les comptes existent bel et bien en base de données.

Ce problème touche potentiellement des milliers de comptes clients d'un coup. Sur une boutique avec 20 000 clients, c'est une urgence commerciale. Voyons pourquoi cela arrive et comment y remédier proprement.

Pourquoi les connexions échouent après un upgrade

La cookie key : le cœur du problème

PrestaShop utilise une clé de chiffrement unique appelée cookie key pour hasher les mots de passe des clients. Cette clé est définie dans le fichier de configuration de votre boutique.

Sur PrestaShop 1.6 et 1.7, elle se trouve dans config/settings.inc.php :

define('_COOKIE_KEY_', 'cragrmv2ctty3eg8o548v8yokwixwxcllpu4vdz1xmem648t2mqrmfac');

Sur PrestaShop 8.x, elle est migrée dans app/config/parameters.php (ou .env) :

'cookie_key' => 'votre_cle_unique_ici',

Lorsque vous effectuez une mise à jour — surtout si vous réinstallez PrestaShop puis importez votre base de données — une nouvelle cookie key est générée automatiquement. Or, tous les mots de passe en base ont été hashés avec l'ancienne clé. Résultat : PrestaShop tente de vérifier le mot de passe saisi avec la nouvelle clé, le hash ne correspond plus, et la connexion est refusée.

L'évolution du hashage des mots de passe

L'autre facteur à comprendre est l'évolution de l'algorithme de hashage :

Version PrestaShopAlgorithmeMéthode 1.4 et antérieurMD5 simple`md5($cookie_key . $password)` 1.5 – 1.6MD5 avec cookie key`md5($cookie_key . $password)` 1.7+bcrypt`password_hash()` natif PHP 8.xbcrypt (renforcé)`password_hash()` avec cost factor ajusté

Si vous migrez depuis une version 1.4/1.5 vers 1.7 ou 8.x, vos mots de passe sont en MD5 alors que le système attend du bcrypt. C'est la double peine.

Diagnostic : confirmer la cause

Étape 1 : Vérifier la cookie key

Comparez la cookie key de votre sauvegarde avec celle du nouveau site.

Sur PrestaShop 1.6/1.7 :

# Sur votre backup
grep '_COOKIE_KEY_' /chemin/backup/config/settings.inc.php

# Sur le nouveau site
grep '_COOKIE_KEY_' /chemin/nouveau/config/settings.inc.php

Sur PrestaShop 8.x :

grep 'cookie_key' /chemin/nouveau/app/config/parameters.php

Si les valeurs diffèrent, vous avez trouvé la cause.

Étape 2 : Vérifier le format des mots de passe en base

SELECT id_customer, email, LEFT(passwd, 10) AS passwd_preview, LENGTH(passwd) AS passwd_length
FROM ps_customer
LIMIT 10;

• **Longueur 32 caractères** → hash MD5 (ancien format)
• **Commence par `$2y$`** → hash bcrypt (format moderne)

Si tous vos mots de passe font 32 caractères, vous êtes face à des hash MD5 hérités.

Les 3 solutions

Solution 1 : Restaurer la cookie key d'origine (recommandé)

C'est la solution la plus simple et la moins invasive. Il suffit de reporter l'ancienne cookie key dans la configuration du nouveau site.

Sur PrestaShop 1.6/1.7 :

Éditez config/settings.inc.php et remplacez la nouvelle cookie key par l'ancienne :

define('_COOKIE_KEY_', 'votre_ancienne_cle_ici');

Sur PrestaShop 8.x :

Éditez app/config/parameters.php :

'cookie_key' => 'votre_ancienne_cle_ici',

Puis videz le cache :

php bin/console cache:clear --env=prod

Avantage : tous les clients retrouvent leur accès immédiatement, sans aucune action de leur part.

Prérequis : vous devez avoir conservé une sauvegarde de vos fichiers de configuration avant la mise à jour. C'est pour cette raison qu'une sauvegarde complète (fichiers + base de données) est indispensable avant toute migration.

Solution 2 : Migration progressive des mots de passe (bcrypt)

Si vous n'avez plus la cookie key d'origine, ou si vous souhaitez profiter de la migration pour passer tous les mots de passe en bcrypt, vous pouvez modifier la logique d'authentification pour gérer les deux formats.

Créez un override de la classe Customer :

// override/classes/Customer.php
class Customer extends CustomerCore
{
    public function getByEmail($email, $plaintextPassword = null, $ignoreGuest = true)
    {
        $customer = parent::getByEmail($email, null, $ignoreGuest);
        
        if (!Validate::isLoadedObject($customer)) {
            return false;
        }
        
        if ($plaintextPassword === null) {
            return $customer;
        }
        
        // Vérification bcrypt moderne (PrestaShop 1.7+/8.x)
        if (password_verify($plaintextPassword, $customer->passwd)) {
            return $customer;
        }
        
        // Fallback MD5 legacy avec l'ancienne cookie key
        $legacyCookieKey = 'VOTRE_ANCIENNE_COOKIE_KEY';
        $legacyHash = md5($legacyCookieKey . $plaintextPassword);
        
        if ($legacyHash === $customer->passwd) {
            // Rehash en bcrypt pour la prochaine connexion
            $customer->passwd = password_hash($plaintextPassword, PASSWORD_BCRYPT);
            $customer->save();
            
            return $customer;
        }
        
        return false;
    }
}

Avantage : migration transparente et progressive. Chaque client qui se connecte voit son mot de passe automatiquement converti en bcrypt.

Inconvénient : les clients qui ne se reconnectent jamais garderont un hash MD5 en base.

Solution 3 : Réinitialisation par email (dernier recours)

Si vous n'avez ni l'ancienne cookie key, ni la possibilité de mettre en place la solution 2, il reste l'option de demander à vos clients de cliquer sur « Mot de passe oublié ».

Pour limiter l'impact, envoyez un email proactif :

// Script de notification en masse
$customers = Customer::getCustomers(true);

foreach ($customers as $customerData) {
    $customer = new Customer($customerData['id_customer']);
    
    // Générer un token de réinitialisation
    $token = md5(uniqid(mt_rand(), true));
    $customer->reset_password_token = $token;
    $customer->reset_password_validity = date('Y-m-d H:i:s', strtotime('+72 hours'));
    $customer->save();
    
    // Envoyer l'email personnalisé
    Mail::Send(
        (int) Configuration::get('PS_LANG_DEFAULT'),
        'password_query',
        'Mise à jour de votre compte - Action requise',
        [
            '{email}' => $customer->email,
            '{lastname}' => $customer->lastname,
            '{firstname}' => $customer->firstname,
            '{url}' => Context::getContext()->link->getPageLink(
                'password',
                true,
                null,
                'token=' . $token . '&id_customer=' . (int) $customer->id . '&reset_token=' . $token
            ),
        ],
        $customer->email,
        $customer->firstname . ' ' . $customer->lastname
    );
}

Avantage : aucune modification technique du système d'authentification.

Inconvénient : friction utilisateur importante, risque de perte de clients inactifs.

Bonnes pratiques pour éviter ce problème

Avant toute mise à jour

1. **Sauvegardez vos fichiers ET votre base de données** — c'est non-négociable
2. **Notez votre cookie key** dans un endroit sûr, séparé de la sauvegarde
3. **Testez la migration sur un environnement de staging** avant de toucher à la production
4. **Documentez la version source et la version cible** de votre migration

Checklist post-migration

# 1. Vérifier que la cookie key est correcte
grep '_COOKIE_KEY_' config/settings.inc.php

# 2. Tester une connexion client
curl -X POST https://votre-boutique.com/connexion \
  -d 'email=client-test@example.com&password=test123'

# 3. Vérifier les logs d'erreur
tail -f var/logs/prod.log | grep -i 'auth\|login\|password'

# 4. Contrôler le format des mots de passe en base
mysql -e "SELECT COUNT(*), LENGTH(passwd) FROM ps_customer GROUP BY LENGTH(passwd);"

Cas particulier : migration depuis PrestaShop 1.4

Les boutiques migrant depuis PrestaShop 1.4 (ou antérieur) ont un défi supplémentaire : les mots de passe étaient hashés en MD5 simple, sans cookie key. Le hash était simplement md5($password).

Dans ce cas, la solution 2 doit être adaptée :

// Fallback MD5 sans cookie key (PrestaShop 1.4)
$legacyHashNoCookie = md5($plaintextPassword);
if ($legacyHashNoCookie === $customer->passwd) {
    $customer->passwd = password_hash($plaintextPassword, PASSWORD_BCRYPT);
    $customer->save();
    return $customer;
}

Conclusion

La perte d'accès des clients après une migration PrestaShop est presque toujours liée à un changement de cookie key ou à une incompatibilité d'algorithme de hashage. La solution la plus fiable reste de restaurer l'ancienne cookie key — d'où l'importance capitale de sauvegarder ses fichiers de configuration avant toute opération de mise à jour.

Pour les migrations importantes (1.6 → 8.x par exemple), la solution de rehashage progressif offre le meilleur compromis entre sécurité et expérience utilisateur.