Closed kiwifraise closed 10 years ago
Bon, j'ai commencé mes petites recherches, je suis sur hébergement mutualisé LWS, et il semblerait que je n'ai pas accès à la fonction Exec, puisque les 2 exec sur les fichiers request et response retournent un code 4. Vraiment pas d'autres solutions ? :'(
Des solutions il y en a toujours, reste à savoir si elles vous plairont ;-)
Merci pour ta réponse. Pour LWS, je sais bien. Mais c'est le client qui avait déjà ce truc, après de toutes façons si je galère trop, je vais simplement ordonner au client que s'il ne change pas d'hébergement (j'ai plusieurs dédiés so...), j'annule le projet pour empêchement technique. Faut pas pousser non plus :) J'ai continue mes recherches, et LWS propose de désactiver le safe-mode (24h d'attente, je l'ai désactivé on verra ce que ça donne), et surtout, propose l'installation d'une paybox / ATOS, en mettant à disposition les 2 fichiers request et response dans leur repertoire "exec_dir/" Chose que j'ai activée, et donc changé le rép dans le module pour aller taper sur exec_dir.
Et là j'ai un code 255 :-1:
Bref, la suite un peu plus tard...
Bon, suite des opérations, les 2 fichiers request et response dans le repertoire exec_dir/ sont bien là, et le module les voit bien. Sauf que :j'avais toujours l'erreur suivante dans le BO :
Error when calling response binary, system exit code: 255, text output: !-1!Invalid Keyword in parameter ('message=012345')!!
De plus, en Front Office, au moment de cliquer sur le moyen de paiement CB, j'avais l'erreur suivante :
blabla
Invalid Keyword in parameter ('language=fr')
blabla
Je me document un peu plus dans la doc d'ATOS, fouille un peu plus loin sur http://thierry-godin.developpez.com/php/atos/#LII-E-3 et me rends compte qu'il n'y a pas d'apostrophes autour des paramètres. Hors dans le module TGG j'en vois... (dixit l'erreur.log)
J'me dis qu'on va virer tout ça histoire de tester (j'en étais plus à ça près), donc dans tggatos.php, ligne 2220, je remplace la ligne par la même sans array_map et le escapeshellarg. Oui bon spa bien, enfin je sais pas encore..
//$args = ' ' . implode(' ', array_map('escapeshellarg', $args));
$args = ' ' . implode(' ', $args);
Et là, tout fonctionne !
Étrange, on dirait un problème de Magic Quotes PHP. Les apostrophes sont nécessaires, si un argument contient un espace ou un caractère spécial du système (un point d'exclamation ou le symbole $ par exemple) le résultat est imprévisible (enfin si, on prévoit très facilement que le résultat ne sera pas celui attendu).
Ben justement, je lis que response.exe prends les arguments séparés par un espace, mais il ne faut pas d'apostrophes. (la preuve, en virant les apostrophes ça fonctionne alors qu'avec, non) Bon je vais remettre le "escapeshellarg" mais je vais faire un trim(''',$var) histoire qu'il traite bien l'intérieur du paramètre. Etrange tout ça :) Je suis en pré-production (pas trouvé de certif de démo), je vais tester tout ça avec le certif de prod. (et après, validation par la banque) Anyways, LWS = hébergeur en carton ça se confirme, et sinon, ton module, good job !!
Ahhh mais c'est sous Windows ?
Dans ce cas ta version de PHP est buggée, escapeshellarg()
est supposée utiliser des guillemets doubles et non des simples. En effet en ligne de commandes sous windows c'est ainsi que l'on procède.
Non, c'est du linux. Mais chaque paramètre est entouré de guillemets simples (') et non doubles. J'ai pas testé de voir si ça fonctionne avec des guillemets doubles. :)
Tiens d'ailleurs, je ne connais même pas la version de request et response... je sais même pas s'ils utilisent de vieilles version :D
Ah désolé, la mention de response.exe
portait à confusion.
Pas la peine de tester avec des guillemets doubles sous Linux, Linux utilise des guillemets simple pour délimiter les arguments (lorsque l'on utilise des guillemets doubles cela permet seulement de réunir en un unique argument une chaîne de caractère contenant des espaces, mais les caractères spéciaux sont tout de même interprétés, ce que l'on ne veut surtout pas dans notre cas).
Ben justement, je lis que response.exe prends les arguments séparés par un espace, mais il ne faut pas d'apostrophes. (la preuve, en virant les apostrophes ça fonctionne alors qu'avec, non)
Cela n'a rien à voir avec les binaires SIPS, cela a a voir avec le système : Lorsque vous appelez un programme en lignes de commandes, le système interprête les caractères spéciaux et découpe la ligne en une commande et un tableau d'arguments, il lance ensuite la commande en lui transmettant tableau d'arguments. Ce ne sont donc pas les commandes qui découpent la partie arguments de la ligne de commande mais bien le système. Et c'est à ce moment qu'interviennent les guillemets pour empêcher l'interprétation de caractères/séquences ayant une signification particulière pour le système et empêcher qu'un espace dans un argument fasse que celui ci soit vu comme deux arguments.
Le meilleurs moyen de t'en assurer est de te connecter en SSH et de lancer manuellement les lignes de commande d'appel aux exécutables SIPS, tu verras alors (normalement) que tu peux sans problème utiliser des guillemets simples autour de chaque argument.
Petit exemple concret : mettons que tu veuilles ouvrir un shell MySQL, sachant que le mot de passe contient un espace, disons mon mot de passe
.
Si tu lances mysql -pmon mot de passe
, mysql va recevoir quatre arguments : -pmon
mot
de
passe
, et comprendra que le mot de passe est mon
.
Si tu lances mysql '-pmon mot de passe'
il recevra alors bien un unique argument -pmon mot de passe
(il ne recevra pas les guillemets simples qui sont retirés par le système !) et comprendra donc bien que le mot de passe est mon mot de passe
.
Oui, je sais bien tout ça. :) Mais c'est curieux que ce mode de fonctionnement ne passe pas chez LWS. Enfin de toutes façon, c'est le seul client chez LWS, et je ne conseille pas, c'est lent, pas de SSH, etc.. :D Encore merci pour ta réponse complète. :) Bon, je passe en production d'ici peu et je te dirai ;)
<troll>
LWS :
</troll>
Bonjour,
(J'écris en français... :) )
Je viens de trouver ton module, ayant un epayment à mettre en place pour un client, sur un PS 1.6.0.6.
J'ai installé ton module (par upload FTP, car via l'interface PS admin, le module n'apparaît pas du tout.. j'ai pas checké en détails mais il n'avait pas l'air d'avoir été téléchargé par PS)
Récup du certificat de production (pas d'infos sur un certif de démo...) auprès de la banque du client.
Configuration OK, test du paiement sur un produit à 1€.
Dès que je valide la commande (après avoir choisi "Payer par carte"), j'ai le message suivant :
Paiement par carte Paiement par carte Vous avez choisi de payer par carte. La transaction s'effectuera sur un serveur bancaire sécurisé où les informations nécessaires vous seront demandées. A n'importe quel moment vous pourrez revenir au choix des moyens de paiement sur notre boutique en cliquant sur le bouton d'annulation depuis le serveur bancaire. Total à payer : 1,00 €
Le paiement par carte est indisponible jusqu'à demain.
Est-ce qu'il faut que je m'affole car cela ne fonctionne pas, ou est-ce un message retourné par la banque en elle-même ? Je n'ai pas trouvé cette phrase dans les fichiers PHP du module, donc je me dis que c'est une erreur externe et non propre au module mais je voulais juste en avoir l'assurance. Est-ce la plateforme ATOS ?
Infos : Banque : mercanet (BNP) PS 1.6.0.6 (fresh install) PHP 5.3 Module tggatos : 3.3.1 (RC).
Merci encore, et quand tout sera OK (mise en production, etc), je n'hésiterai pas à faire un don pour ce super boulot !