Powerbook1800 Posted March 9, 2018 Share Posted March 9, 2018 (edited) Bonjour à tous, Après de long travaux de préparation, répétition et autres... j'ai pu réaliser ma migration d'un vénérable PS1.4.2.8 vers un PS1.7.2.4. Cette migration a pu être mise en production, mais suite à la découverte d'un gros problème par un client qq heures après la mise en production il a fallu faire un rollback malheureusement. Coté PS1.7.2.4 (version stable disponible quand j'ai commencé mes travaux de préparation): Aucune modification du code de la boutique ou autre. La seule "modification" c'est la valeur du "cookie_key" dans parameters.php avec la valeur "historique" de la boutique en PS1.4 pour que les clients puissent se connecter à la boutique après migration vers le PS 1.7 (et cela fonctionne bien). Après investigation, le problème est commun à tous types d'utilisateurs : "anciens" c.a.d migré ou pour un utilisateur "nouveau" c.a.d créé après la migration. Cas d'usage : un client existant ou nouveau (il vient de s'enregistrer), rempli un panier, sélectionne le transporteur, le moyen de paiement (Paypal / Payplug, virement ou chèque), valide le paiement -> Tout est parfait, mails envoyés au client, BO à jour -> c'est nickel. Un client existant avant la migration, ou le nouveau qui vient de créer son compte, change son mot de passe, soit par sa fiche personnelle ou par "mot de passe oublié". Tout se passe bien, après changement du mot de passe, la connexion sur la boutique est OK. De nouveau ce client rempli un panier, transporteur, choix d'un moyen de paiement, au retour du paiement et la c'est le drame : - Coté client : "Erreur fatale" - BO : pas de commande - Le paiement a bien été réalisé (paypal, payplug), c'est donc bien au retour vers la boutique que ça explose. - logs : "PaymentModule::validateOrder - Secure key does not match" C'est la même "punition" qqsoit le moyen de paiement (chèque, virement, PayPal ou Payplug). Le problème apparait donc quand le client change son mot de passe. Je lance un S.O.S si qqun à une idée, piste ou la solution... Merci d'avance pour votre aide. Edited March 9, 2018 by Powerbook1800 (see edit history) Link to comment Share on other sites More sharing options...
Laur31000 Posted March 28, 2018 Share Posted March 28, 2018 Bonjour j'ai aujourd'hui le même problème que toi . As tu trouvé une solution ? Link to comment Share on other sites More sharing options...
alex Posted July 23, 2018 Share Posted July 23, 2018 Bonjour, Avez-vous pu solutionner le problème je suis EXACTEMENT dans le même cas et ca me fait perdre des commandes, je suis totalement perdu pour regler le soucis :((( Merci à vousssss Link to comment Share on other sites More sharing options...
Matthieu Brunet Posted December 6, 2018 Share Posted December 6, 2018 Bonjour à tous, J'ai l'impression d'avoir le même genre de problème ici : certains clients n'arrivent pas à valider leur commande, et j'ai plein d'erreurs comme ça dans les logs : PaymentModule::validateOrder - Secure key does not match Link to comment Share on other sites More sharing options...
Powerbook1800 Posted December 6, 2018 Author Share Posted December 6, 2018 Bonjour Matthieu, J'avais "posté" ce problème après une migration PS1.4 -> 1.7 avec un module de migration 'MigrationPro" pour ne pas les citer (j'ai passé 2 mois a débugger leur module, cela n'a jamais fonctionné à 100%...). Le problème était lié à mes clients "avant migration", si le client changeait son mot de passe, j'avais cette erreur. La "solution" de la société qui éditait le module avait été de supprimé la vérification dans le module "ValidateOrder", pffffff c'est c'est du correctif ! Comme j'ai eu bien d'autres problèmes avec la migration de ma boutique, j'ai stoppé mon projet de migrer vers une 1.7. et avant de perdre totalement la tête et stopper les heures et les heures de tentatives de migrations infructueuses, j'ai eu recours à un spécialiste Prestashop... qui c'est occupé de la migration avec succès (vers le dernier PS1.6). Je peux passer l'échéance de l’arrêt de PHP5.x sereinement maintenant. Bref cela ne va pas t'aider tout ça... Tu as fait des modifications de la config ou autre sur ta boutique site dernièrement ? Bon courage. ++ Powerbook. Link to comment Share on other sites More sharing options...
Matthieu Brunet Posted December 7, 2018 Share Posted December 7, 2018 On a fait une mise à jour (1.7.x -> 1.7.3) il y a quelques semaines. Mais a priori, les erreurs n'ont commencé que cette semaine... En même temps, on rentre dans la période où le nombre de commandes augmente énormément, et du coup forcément, statistiquement, les erreurs ont plus de chances de se produire... Link to comment Share on other sites More sharing options...
Howie Posted July 24, 2019 Share Posted July 24, 2019 Bonjour, je rencontre de plus en plus souvent ce problème ces derniers jours sur une boutique en 1.7.5.2, aussi bien avec Paypal que par paiement CB via Monetico. Aucune mise à jour récente n'a été faite de PS ou de modules. Paypal et Monetico sont bien à jour. J'ai vu sur GitHub que quelqu'un avait un problème d'ajout de produit au panier par le module Mailchimp qui créait un problème de correspondance d'ID panier/commande, mais je n'ai pas ce module chez moi. Est-ce que quelqu'un rencontre encore ce problème ? A-t-il été résolu, et de quelle manière ? Merci pour votre aide. Link to comment Share on other sites More sharing options...
Howie Posted July 25, 2019 Share Posted July 25, 2019 (edited) Bonjour, Problème identifié pour ma part. En regardant les tables _cart et _customer, j'ai vu que la valeur du champ secure_key était différente entre les deux. J'ai en fait 2 comptes client identiques (hormis l'ID). La récupération et le contrôle de la valeur secure_key se faisait sur l'id client le plus récent, alors que celle du panier était sur le plus ancien. Reste à comprendre comment je peux avoir deux comptes client créés en même temps... Edited July 25, 2019 by Howie (see edit history) 1 Link to comment Share on other sites More sharing options...
Jgoss Posted June 17, 2020 Share Posted June 17, 2020 (edited) Merci @Howie je viens d'avoir exactement le même souci (1.7.5.1 en l'occurence), et ton diagnostic m'a bien aidé ! Une idée de comment ce genre de situation peut arriver (double création de compte) ? C'est un peu problématique quand même ... Edited June 17, 2020 by Jgoss (see edit history) Link to comment Share on other sites More sharing options...
Mapoli Posted October 25, 2021 Share Posted October 25, 2021 Bonjour, Personne n'a de réponse en 2021 ? J'ai le meme souci Link to comment Share on other sites More sharing options...
Laetitia Bordon Posted April 5, 2023 Share Posted April 5, 2023 Merci @Howie J'ai eu ce soucis pour 1 user et, en regardant en db, j'ai vu que la secure key avait changé. Etant dans un environnement app, je n'ai pas accès aux script pour faire afficher la secureKey qu'il prenait. Du coup, en db, j'ai mis la secure key dans le champs note (pour encore l'avoir au cas où) et, dans secure key, j'ai remis l'ancienne et là, o miracle, ça fonctionne Donc, merci merci merci pour ton post. Ce qui m'étonne, c'est qu'il avait su passer des commandes avec l'autre securekey mais que, depuis janvier, ça donnait une erreur fatale lors de la confirmation de commande... @Mapoli Si votre souci persiste (pour 1 user) et que vous avez accès à la db (avec un phpMyAdmin par exemple), vérifiez dans ps_orders pour ce user s'il y a une securekey différente de celle qui se trouve dans ps_customer. Si oui, mettez l'actuel secureKey de ps_customer dans le champs note (juste en-dessous) et, dans securekey, mettez celle de ps_order qui est différente. Cela a fonctionné pour moi (version 1.7.6.5) Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now