Version imprimable du sujet

Cliquez ici pour voir ce sujet dans son format original

Forum osCommerce-fr _ Solutions de paiement sur Internet _ Problème de validation commande ATOS et php5.3

Écrit par : Gnidhal 14 Feb 2012, 21:07

Bonjour à tous,
Après avoir du mettre à jour ma version de PHP sur mon dédié j'ai rencontré un problème de validation des commandes payées par Citélis via Atos.
Notez au passage que Citélis n'a rien à voir là dedans car Atos est aussi utilisé par de nombreux autres systèmes de paiement.
Je voulais passer en php 5.2.x mais mon système de mise à jour Plesk m'a obligé à prendre un PHP 5.3.3
Bon, ok, mes scripts étaient prêts pour le 5.3 mais j'ai rencontré le problème des retours de paiement maintes fois cités ici pour lequel aucune réponse n'a été trouvée.


Des dizaines d'essais, des traceurs dans les scripts, l'observation des logs m'ont amené à constater que la session n'était pas récupérée dans checkout_process.php directement appelé par le serveur de la banque.
Le module Atos comporte en effet 3 lignes qui doivent normalement être renseignées comme suit :

Code
      $command .= " " . $this->os_info['quote'] . "normal_return_url=" . tep_href_link('atos_response.php', tep_session_name() . '=' . tep_session_id(), $request_type, false) . $this->os_info['quote'];
      $command .= " " . $this->os_info['quote'] . "cancel_return_url=" . tep_href_link('atos_response.php', tep_session_name() . '=' . tep_session_id(), $request_type, false) . $this->os_info['quote'];
      $command .= " " . $this->os_info['quote'] . "automatic_response_url=" . tep_href_link(FILENAME_CHECKOUT_PROCESS, tep_session_name() . '=' . tep_session_id(), $request_type, false) . $this->os_info['quote'];

On voit que le retour de validation se fait directement sur checkout_process avec en paramètre GET l'identifiant de session alors que les autres retours se font via atos_response
Mais si votre boutique n'utilise pas le SSL cela pose problème : l'id de session n'est pas rechargé et donc les infos de panier et du client sont absentes.

J'ai réussi à fixer cela très simplement comme suit:
dans application_top.php rechercher :
Code
// set the session ID if it exists
   if (isset($_POST[tep_session_name()])) {
     tep_session_id($_POST[tep_session_name()]);
   } elseif ( ($request_type == 'SSL') && isset($_GET[tep_session_name()]) ) {
     tep_session_id($_GET[tep_session_name()]);
   }
et le modifier en
Code
// set the session ID if it exists
   if (isset($_POST[tep_session_name()])) {
     tep_session_id($_POST[tep_session_name()]);
   } elseif ( isset($_POST['DATA']) && isset($_GET[tep_session_name()]) ) {
     tep_session_id($_GET[tep_session_name()]);
   } elseif ( ($request_type == 'SSL') && isset($_GET[tep_session_name()]) ) {
     tep_session_id($_GET[tep_session_name()]);
   }

et hop, ça roule. smile.gif
Notez au passage que j'ai remplacé $HTTP_POST_VARS par $_POST car la notation $HTTP_XXX_VARS est obsolète et normalement liée à une utilisation register_globals sur on ce qui n'est plus d'actualité dans les version 2.3.1 et suivantes.

Tous les autres bricolos proposés ici et là sont ineffectifs et attention, la dernière version du module Atos proposée par Telede (2.8.1) comporte une erreur que je fixerai dès que possible proprement :
lignes 178 à 180 on a :
Code
      // Adjust cart
      //
      $product_query = tep_db_query('DELETE FROM ' . TABLE_CUSTOMERS_BASKET . ' WHERE customers_id = "' . (int)$customer_id . '" AND customers_basket_id NOT IN (' . $customers_basket_ids . ')');

commentez la ligne 180 qui présente 2 erreurs : une de syntaxe dans la requête, un autre dans le fait que la variable $customer_id n'existe pas ici car elle n'est pas globale.
Comme cette ligne n'est pas vitale pour le fonctionnement ou la sécurité, j'ai choisi de la supprimer simplement. Je ferai un update de la contribution ultérieurement.

Écrit par : telede 15 Feb 2012, 08:21

Salut smile.gif

Effectivement je me suis jamais penché sur ce qui faisait défaut sur PHP 5.3 : j'ai ouvert des portes dans des topics mais on ne m'a pas répondu ...

Donc bien vu pour le correctif wink.gif

Par contre, simple curiosité personnelle, peux tu me dire ce qui diffère entre 5.2 et 5.3 qui engendre cette erreur ? car le traitement est le même ...

Pour la partie panier (l'effacement), désolé, j'avais pas vu l'erreur, je corrigerais si tu ne l'as pas fait d'ici là.

PS : tu as bu ou quoi ? je n'ai jamais vu autant de fautes d'orthographe dans l'un de tes topics tongue.gif

Écrit par : Gnidhal 15 Feb 2012, 09:10

Non rien bu, mais parfois la fatigue de fin de journée m'amène à oublier quelques règles élémentaires d'accord smile.gif

Je pense que la cause est le mode de connexion SSL ou non.
Dans application_top tu ne peux passer l'id de session en get si la connexion n'est pas SSL.
le lien est construit dans le module ATOS autour de la variable $request_type qui détermine le SSL
Il me semble donc que la cause est de ce coté et dans ce cas à rapprocher de la ligne application_top qui contient getenv('HTTPS').
En effet, selon la config PHP, cette requête ne retourne pas forcément 'on' mais peut-être 1 ou autre chose...

Par ailleurs comment peut-on récupérer un lien SSL visiblement obligatoire si on a pas configuré sa boutique en SSL ?
J'ai pas creusé et j'ai fixé en testant la variable POST 'DATA' ce qui ne présente pas de problème de sécurité car la validation de la commande ne peut se faire si justement cette variable $_POST['DATA'] n'est pas correctement remplie et que la requête ne vient pas du serveur de banque.

Pour ce qui est du fix de la contrib, je te laisse faire si tu veux. Mais ton procédé "anti hack" me parait superflu wink.gif

Écrit par : telede 16 Feb 2012, 05:01

Merci pour le debriefing wink.gif

Citation (Gnidhal @ 15 Feb 2012, 09:10) *
Pour ce qui est du fix de la contrib, je te laisse faire si tu veux. Mais ton procédé "anti hack" me parait superflu wink.gif

C'est là ou justement, de mémoire car cela fait longtemps que je n'ai pas mis la tête dans ce code, qu'il faut que le delete dans le customer basket s'opère, donc il faut corriger ça :

Citation (Gnidhal @ 14 Feb 2012, 21:07) *
commentez la ligne 180 qui présente 2 erreurs

Pas la commenter !


Écrit par : zef72 21 Feb 2012, 11:15

merci Gnidhal !!

Écrit par : frogger74 21 Mar 2012, 14:39

Oui merci Gnidhal !!

Écrit par : Gnidhal 21 Mar 2012, 14:52

je suppose que tu parles de la 2.3.1 et non de la 2.1.3 wink.gif
Non pas très différent à l'exception du fait que $_POST est écrit $HTTP_POST_VARS mais j'explique plus haut cette différence de notation des variables $_GET et $_POST
Compares le code en place et le code que je fournis

Écrit par : frogger74 21 Mar 2012, 14:57

Oui après coup , j'ai vue que le code que tu fourni fonctionne également en OSC 2.1.3, j'avais mal lu , merci encore.

Désolé. rolleyes.gif

Écrit par : milerwan 8 Jul 2012, 11:26

Bonjour,

Je suis actuellement en MS2.2 + PHP5.3 et parmi toutes les contributions disponibles (2.8, 3.2) aucune ne fonctionne chez moi.
J'ai toujours ce problème de panier plein et de commande non créée malgré un paiement CB accepté.

J'ai bien essayé de combiner ton code Gnidhal avec les autres contribs mais rien n'y fait... :/

Où puis-je trouver une contribution cohérente qui tienne compte de ma version d'Osc et du niveau PHP5.3 du serveur ?
Les 2 peuvent-ils être compatibles ensemble avec ATOS ou faut-il nécessairement upgrader OsC en 2.3 ?

Merci de votre aide.

Écrit par : fredfredfred 26 Mar 2013, 15:25

bonjour, pas eu de réponse ? car même pb ici....

Écrit par : BeHuman 21 May 2013, 07:47

perso pour le retour atos vers checkout_process sur un serveur Ubuntu 12.04 ayant php5.3 sur une contrib MS2 j'ai juste ajouter ça au tout début du fichier checkout_process.php:

Code
$HTTP_GET_VARS['osCsid']  = $_GET['osCsid'];
$HTTP_POST_VARS['osCsid'] = $_GET['osCsid'];
$HTTP_COOKIE_VARS['cookie_test'] = true;

ça peut paraître barbare mais ça fonctionne correctement

si ça peut aider wink.gif ++

PS: ce hack de session est vraiment crado, donc si l'un d'entre vous à une solution plus propre je suis preneur aussi. Cependant je me suis vite rendu qu'il n'y avait pas de solution miracle, la seul de vraiment efficace serait de revoir le système de variable de session dans ça globalité, se que j'ai fait pour mon support mobile mobi.chronocarpe.com qui lui n'a pas eu besoin de bidouille plus ou moins foireuse pour fonctionner correctement.

Propulsé par Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)