Fonction exec() interdite par mon hébergeur : une solution ?

kiwifraise commented 10 years ago

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 !

kiwifraise commented 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 ? :'(

TrogloGeek commented 10 years ago

Des solutions il y en a toujours, reste à savoir si elles vous plairont ;-)

Changer d'hébergeur : J'ai plusieurs fois eu à travailler chez LWS, choix de clients, et j'ai toujours eu des soucis chez cet hébergeur. Vous pouvez toujours à tout hasard les contacter pour savoir si ils acceptent de faire sauter la restriction, mais personnellement c'est un hébergeur que j'évite comme la peste (une configuration qui ne me plait pas du tout, mais bon, c'est très subjectif, trop de restrictions qui au final coûtent cher en maintenance et développement des applications, et puis trop de défaillances réseau constatées chez eux, on a perdu des journées entières de planning à attendre qu'ils réparent...), il vaut mieux éviter de trop regarder à l'économie sur les hébergement, car au final vous ne serez pas forcément gagnant financièrement !
Utiliser une implémentation Perl (pourquoi interdire la fonction exec() mais autoriser les scripts Perl ? D'un point de vue sécurité, cela n'a pour moi aucun sens...), je connais (de nom) celle ci : http://www.pierreyves.be/2010/03/16/module-atos-cgi-perl/ Je n'ai jamais eu le module entre mes mains, donc je ne saurais vous dire si qualité, fiabilité et sécurité sont au rendez-vous. (Que l'on se comprenne bien, je ne prétends absolument pas que ce n'est pas le cas, simplement je n'en ai strictement aucune idée.)

kiwifraise commented 10 years ago

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...

kiwifraise commented 10 years ago

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 !

TrogloGeek commented 10 years ago

É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).

kiwifraise commented 10 years ago

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 !!

TrogloGeek commented 10 years ago

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.

kiwifraise commented 10 years ago

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

TrogloGeek commented 10 years ago

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.

kiwifraise commented 10 years ago

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 ;)

TrogloGeek commented 10 years ago

<troll> LWS :

Le Web Sacrilège ?
Le Web Stupide ?
Lamentable Web Service ?

</troll>

TrogloGeek / prestashop-tggatos-module

Fonction exec() interdite par mon hébergeur : une solution ? #31

Le paiement par carte est indisponible jusqu'à demain.