Erreur sur fichiers request et response

Bonjour,

J'ai un problème avec le paramétrage de la Méthode de paiement SIPS ATOS sur les fichiers request et réponse.

La banque postale m'a fournit 4 fichiers dans 2 répertoires différents : Static et glibc-2.5-42. D'après ce que j'ai lu sur le forum, c'est celui du répertoire glibc-2.5-42 qu'il faut utiliser. A confirmer ...

J'ai téléchargé en FTP les deux fichiers (car impossible avec le plugin : sans doute dû au SafeMode) dans le répertoire /www/media/com_hikashop/b, j'ai ensuite modifié les droits pour les mettre en 755 puis j'ai regardé le Pathfile dans /www/media/com_hikashop

Les paramètres du Pathfile :
DEBUG!NO!
D_LOGO!/media/com_hikashop/l/!
F_DEFAULT!/home/www/media/com_hikashop/pc.x!
F_PARAM!/home/www/media/com_hikashop/pc!
F_CERTIFICATE!/home/www/media/com_hikashop/b/ct!

Impossible de paramétrer la méthode pour les deux fichiers (qui sont déjà sur le serveur).

Sur la boutique :

Warning: exec() has been disabled for security reasons in /home/www/plugins/hikashoppayment/atos/atos_end.php on line 50

erreur appel request

executable request non trouve /home/www/media/com_hikashop/b/request

Je n'ai pas trouvé malgré les posts sur le forum comment régler ce problème de fichiers Request et Response.

Si quelqu'un pouvait m'aider à configurer le module !!!

Merci par avance.

Je vois avec l'hébergeur ce qu'il peut faire. Merci

Voici la réponse de l'hébergeur :

Sur votre hébergement premium vous pouvez utiliser la fonction exec() ell fonctionne parfaitement.
Il faut placer vos fichiers exécutables dans le répertoire cgi-bin à la racine de votre hébergement.

Bonjour,

Désolé pour l'intrusion mais le sujet m'intéresse. Priorité bien sûr à l'auteur de ce post.

Ayant un client chez Infomaniak, cet hébergeur n'accepte pas la fonction exec(), et je suis tombé sur de nombreux forums conseillant de changer d'hébergeur pour cette solution de paiement.
Cela m'étonne et me gêne fortement d'autant plus que Infomaniak stipule dans sa FAQ que les solutions de paiement en ligne sont acceptées pour autant qu'on choisisse la version Perl CGI ou HTML.
De plus Infomaniak précise que : le kit de paiement d'Atos doit etre mis à jour pour fonctionner sur la dernière version de nos serveurs, tournant sous Debian Lenny et utilisant la glibc version 2.7.

Comme il existe également un répertoire cgi-bin, je suppose que les fichiers "request" et "response" devront y être placés. Infomaniak précise en plus que "la version à utiliser pour ces fichiers doit être proche de la version V600".

Quelle modifications seront à faire pour utiliser cet emplacement de fichiers différents de celui prévu et quel impact avec les versions Perl CGI ou HTML ?
De plus n'ayant pas encore paramétré de solutions de paiement, je n'ai pas de fichier pathfile dans "media/com_hikashop", c'est normal ?

Merci.

Merci Nicolas, je suppose que la réponse faite à Touchet me concerne aussi pour ce dossier cgi-bin.
Le site devant être mis en ligne avant la fin de la semaine, je reviendrai sur le sujet en temps voulu et si besoin.

A+

Merci à vous tous de faire avancer le sujet mais j'a encore plusieurs interrogations :

- Ou se trouve cette "option des binaires" : dans le plugin HikaShop SIPS Atos paiement plugin ?

- Si je m'en tiens à installer ces fichiers dans le fichier de la documentation media/com_hikashop/b/, comment paramétrer le plugin pour qu'il aille les chercher au bon endroit car vraisemblablement, pour le moment, il ne les trouve pas.

- LA BANQUE POSTALE m'a fait suivre un dossier complet avec des fichiers parcom, pathfile, call_request, call_autoresponse et call_response. Dois-je remplacer ce générer par le plugin par ceux fournis par LA BANQUE POSTALE ?

J'ai beaucoup de questions mais je suis un peu pommé dans tous ces méandres de paramétrages...

Merci par avance pour vos réponses.

Je vois avec ATOS (sous-traitant pour la banque postale) qui doit apparemment me filer un coup de main pour l'intégration de leurs fichiers.

Ils m'ont fournis une documentation sur ce sujet.

On va voir.

Merci encore

Bonjour,

Bon comme vu précédemment l'hébergeur Infomaniak (et peut-être d'autres) n'acceptant pas les fonctions PHP "à risque" comme exec() ou shell_exec(), je vais être obligé d'utiliser des fichiers PERL CGI.

J'ai récupéré un kit ATOS avec à la fois des fichiers PHP et PERL (.pl). Je suppose que je vais devoir configurer correctement et manuellement le plugin ATOS d'Hikashop, en spécifiant le chemin dans lequel je vais placer mes fichiers.

2 questions :
1) dans mon dossier /bin (dans mon kit) j'ai 3 fichiers "request" et 3 fichiers "response"
- request
- request_2.4.18_2.96
- request_2.6.9_3.4.2 (linux ?)
- response
- response_2.4.18_2.96
- response_2.6.9_3.4.2 (linux ?)

Lesquels utiliser ? Y en a t'il dédié à Perl (je suppose que oui) ?

2) comme je vais devoir utiliser des fichiers PERL "call_autoresponse.pl", "call_request.pl", et "call_response.pl", je suppose que je vais devoir mofifier quelque chose pour que ça fonctionne, mais quoi ?

Merci d'avance.

A+

Bon on efface tout et on recommence.

Dans un kit marchand standard ATOS, il existe des fichiers call_request, call_response et call_autoresponse qui contiennent les appels de fichiers binaires. Apparemment le plugin ATOS d'Hikashop n'a pas besoin de ces fichiers (ou de les créer) puisqu'il intègre dans les fichiers atos.php et ato_end.php les appels à ces binaire avec les mêmes fonctions exec($path_bin.....).

J'ai contacté mon hébergeur (Infomaniak) et je lui ai demandé comment utiliser les CGI PERL en lieu et place des fichiers PHP. Il m'a répondu cela :
"Vous devez placer vos scripts CGI tels que vos fichiers .pl dans le répertoire /web/cgi-bin , après quoi vous pouvez appeler votre script normalement via l'action d'un formulaire HTML par exemple.".

Le but étant d'appeler les exécutables via un script PERL et donc de modifier les fichiers "atos.php" et "atos_end.php" pour y inclure un script PERL sachant que l'hébergeur intègre le PERL.

En PHP j'ai vu ça mais je ne sais pas si cela fonctionne (ou si c'est encore d'actualité) :

<?php
$perl = new Perl(); //creation d'une instance perl
$perl->require("script.pl ARG1 ARG2 ..."); //load du script perl
?>

<script language="JavaScript" type="text/javascript"
src="http://www.mydomain.com/cgi-bin/script.pl"
<script>

#!usr/bin/perl

#-------------------------------------------------------------
# Topic	  : Exemple PERL traitement de la requête de paiement
# Version : P600
#
# 	Dans cet exemple, on affiche un formulaire HTML
#	de connection à l'internaute.
#
#-------------------------------------------------------------

payment_request();

sub payment_request
{

# affichage du debut de la page

 print "Content-Type: text/html\n\n";
 print "";
 print "<HTML><HEAD><TITLE>SOGENACTIF - Paiement Securise sur Internet</TITLE></HEAD>";
 print "<BODY bgcolor=#ffffff>";
 print "<Font color=#000000>";
 print "<center><H1>Test de l'API plug-in SOGENACTIF</H1></center><br><br>";

 # Affectation des paramètres obligatoires
 
 $parm="merchant_id=014213245611111";
 $parm=$parm . " merchant_country=fr";
 $parm=$parm . " amount=100";
 $parm=$parm . " currency_code=978";
 
 # Initialisation du chemin du fichier pathfile (à modifier)
 #   ex :
 #    -> Windows : $parm=$parm . " pathfile=c:\\repertoire\\pathfile";
 #    -> Unix    : $parm=$parm . " pathfile=/home/repertoire/pathfile";
 #
 
 	$parm=$parm . " pathfile=chemin_du_fichier_pathfile";
 
 #	Si aucun transaction_id n'est affecté, request en génère
 #	un automatiquement à partir de heure/minutes/secondes
 #	Référez vous au Guide du Programmeur pour
 #	les réserves émises sur cette fonctionnalité
 #
 #	$transaction_id="transaction_id=123456"
 
 
 #	Affectation dynamique des autres paramètres
 #	Les valeurs proposées ne sont que des exemples
 #	Les champs et leur utilisation sont expliqués dans le Dictionnaire des données
 #	
 #	$parm=$parm . " normal_return_url=http://www.maboutique.fr/cgi-bin/call_response.pl";
 #	$parm=$parm . " cancel_return_url=http://www.maboutique.fr/cgi-bin/call_response.pl";
 #	$parm=$parm . " automatic_response_url=http://www.maboutique.fr/cgi-bin/call_autoresponse.pl";
 #	$parm=$parm . " language=fr";
 #	$parm=$parm . " payment_means=CB,2,VISA,2,MASTERCARD,2";
 #	$parm=$parm . " header_flag=no";
 #	$parm=$parm . " capture_day=";
 #	$parm=$parm . " capture_mode=";
 #	$parm=$parm . " bgcolor=";
 #	$parm=$parm . " block_align=";
 #	$parm=$parm . " block_order=";
 #	$parm=$parm . " textcolor=";
 #	$parm=$parm . " receipt_complement=";
 #	$parm=$parm . " caddie=mon_caddie";
 #	$parm=$parm . " customer_id=";
 #	$parm=$parm . " customer_email=";
 #	$parm=$parm . " customer_ip_address=";
 #	$parm=$parm . " data=";
 #	$parm=$parm . " return_context=";
 #	$parm=$parm . " target=";
 #	$parm=$parm . " order_id=";
 
 
 #	Les valeurs suivantes ne sont utilisables qu'en pré-production
 #	Elles nécessitent l'installation de vos fichiers sur le serveur de paiement
 #	
 #	$parm=$parm . " normal_return_logo=";
 #	$parm=$parm . " cancel_return_logo=";
 #	$parm=$parm . " submit_logo=";
 #	$parm=$parm . " logo_id=";
 #	$parm=$parm . " logo_id2=";
 #	$parm=$parm . " advert=";
 #	$parm=$parm . " background_id=";
 #	$parm=$parm . " templatefile=";
 
 
 #	insertion de la commande en base de données (optionnel)
 #	A développer en fonction de votre système d'information

 # Initialisation du chemin de l'executable request (à modifier)
 # ex :
 #    -> Windows : $path_bin = "c:\\repertoire\\bin\\request";
 #    -> Unix    : $path_bin = "/home/repertoire/bin/request";
 #

 $path_bin = "chemin_de_l'executable_request";

 #  Appel du binaire request
 
 open(INFO, $path_bin . " " . $parm . "|");
  for ($result = 0, $i = 0; <INFO>; $i++)
  {
      $result = $result . $_;
  }
 close(INFO);
 
 #	Sortie de la fonction : !code!error!buffer!
 #		- code=0	: la fonction génère une page html contenue dans la variable buffer
 #		- code=-1 	: La fonction retourne un message d'erreur dans la variable error

 # On sépare les différents champs et on les met dans une variable tableau

 @tableau = split("!",$result);

 # recuperation des parametres
 
 $code = $tableau[1];
 $error = $tableau[2];
 $message = $tableau[3];


 # analyse du code retour
 
  if (( $code eq "" ) && ( $error eq "" ) )
 	{
  	print "<BR><CENTER>erreur appel request</CENTER><BR>";
  	print "fichier request non trouve : $path_bin";
     	print "</body></html>";
 	return;
 	};
 
 # Erreur, affiche le message d'erreur 
 
  if ( $code != 0 )
  	{
  	print "<BR><CENTER>erreur apel API de paiement</CENTER><BR>";
  	print "message erreur : $error";
     	print "</body></html>";
 	return;
	};

 print "<br><br>";
 
 # OK, affichage du mode DEBUG si activé
 print "$error";
 print "<br>";
 
 # OK, affiche le message html
 print "$message";
 print "<br>";

 print "</BODY>";
 print "</HTML>";

}

Bonsoir,

Bon j'ai avancé, par où je commence ?

J'ai franchi la première étape, l'appel à REQUEST pour l'affichage des moyens de paiement, le binaire était originalement appelé par la fonction exec($path_bin $parm) dans le fichier "atos_end.php".

Je rappelle que la solution de mon hébergeur, ou plutôt celui de mon client, était d'utiliser des CGI PERL à la place des appels PHP interdits comme exec().
Dans mon kit marchand j'ai conservé les binaires request et response qui étaient dans le dossier /bin/glibc-2.3.4 du kit, et je les ai uploadé via le plugin ATOS d'Hikashop dans mon dossier cgi-bin, en ayant préalablement indiqué ce dossier d'upload pour les binaires.
Le plugin a créé un dossier "b" dans "cgi-bin" et placé les binaires donc dans "/cgi-bin/b", mais aussi le certificat. Les autre fichiers "parmcomxxx" ont été mis dans "/cgi-bin".

Jusque là rien de transcendant. L'objectif suivant était de modifier l'appel à REQUEST avec autre chose qu'un exec() puisque c'est interdit.
J'ai donc :
- modifié le fichier "atos_end.php"
- créé un script PERL (call_request.pl)

Tout d'abord pour atos_end.php, j'ai supprimé les lignes depuis le exec($path_bin $parm) jusqu'à la fin et j'ai ajouté la redirection vers mon script call_request.pl simplement avec un "header(Location: http://xxxxxxxxxx)" dans lequel je passe en paramètres les variables $path_bin et $parm.

Ensuite j'ai donc créé mon script PERL "call_request.pl" que j'ai placé dans "/cgi-bin", celui-ci récupère les variables et contient exactement ce qu'il y avait après la ligne exec() dans "atos_end.php", mais en langage PERL accepté par l'hébergeur.

J'ai mis à jour les droits sur les binaires en 755 ainsi que sur mon script PERL, et j'ai adapté le pathfile, notamment pour les parmcom, comme ci-dessous:

DEBUG!YES!
D_LOGO!/media/com_hikashop/l/!
F_DEFAULT!/home/www/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/web/cgi-bin/parmcom.mercanet!
F_PARAM!/home/www/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/web/cgi-bin/parmcom!
F_CERTIFICATE!/home/www/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/web/cgi-bin/b/ct!

DEBUG MODE

Pathfile
Reading pathfile (/home/www/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/web/cgi-bin/pathfile) OK
D_LOGO (/media/com_hikashop/l/)
F_DEFAULT (/home/www/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/web/cgi-bin/parmcom.mercanet)
F_PARAM (/home/www/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/web/cgi-bin/parmcom)
F_CERTIFICATE (/home/www/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/web/cgi-bin/b/ct)

System
Reading F_DEFAULT (/home/www/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/web/cgi-bin/parmcom.mercanet) OK
Reading F_PARAM (/home/www/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/web/cgi-bin/parmcom.082584341411111) OK
Reading F_CERTIFICATE (/home/www/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/web/cgi-bin/b/ct.fr.082584341411111) OK
Version du certificat = 16/10/2006 (MERCANET)

CALL URL
https://mercanet.bnpparibas.net:443/cgis-payment-mercanet/demo/callpayment

Request sent to the Payment Server
API_VERSION (P615)
CERTIFICATE_DATE (20061016)
CERTIFICATE_EXPIRED ()
CERTIFICATE_VERSION ()
CERTIFICATE_TYPE ()
BROWSER_TYPE ()
MERCHANT_ID (082584341411111)
MERCHANT_COUNTRY (fr)
AMOUNT (450)
TRANSACTION_ID (211741)
CURRENCY (978)
TRANSMISSION_DATE (20120309201741)
PAYMENT_MEANS (CB,2,VISA,2,MASTERCARD,2)
HEADER_FLAG (yes)
LANGUAGE (fr)
RETURN_URL (http://www.xxxxxxx.com/success.php)
CANCEL_URL (http://www.xxxxxxx.com/atos.php)
AUTO_RESPONSE_URL (http://www.xxxxxxx.com/atos.php)
RETURN_LOGO ()
CANCEL_LOGO ()
SUBMIT_LOGO ()
LOGO (mercanet.gif)
LOGO2 (commercant.gif)
ADVERT (advert.gif)
CARD_LIST (CB,VISA,MASTERCARD)
TRANSACTION_CONDITION (SSL)
ORDER_VALIDITY ()
MERCHANT_LANGUAGE (fr)
BGCOLOR (ffffff)
TEXTCOLOR (000000)
TEXTFONT ()
BACKGROUND ()
RECEIPT ()
CADDIE (YToxMTp7czo3OiJhZGRyZXNzIjtzOjIwOiI4IHJ1ZSBQaWVycmUgRnJlc25heSI7czo4OiJhZGRyZXNzMiI7czowOiIiO3M6ODoibGFzdG5hbWUiO3M6NjoiRGV2YXV4IjtzOjc6ImNvdW50cnkiO3M6MzoiRlJBIjtzOjExOiJwb3N0YWxfY29kZSI7czo1OiI4NzAwMCI7czo0OiJjaXR5IjtzOjc6IkxpbW9nZXMiO3M6NToic3RhdGUiO3M6MTI6IkhhdXRlLVZpZW5uZSI7czoxMjoicGhvbmVfbnVtYmVyIjtzOjEwOiIwNTU1MTIzNDU2IjtzOjU6InRpdGxlIjtzOjE6Ik0iO3M6OToiZmlyc3RuYW1lIjtzOjc6IlRoaWVycnkiO3M6NjoiY2FkZGllIjtpOjEyO30=)
CUSTOMER_ID (2)
CUSTOMER_EMAIL (xxxxxx.yyyyyyy@gmail.com)
DATA ()
RETURN_CONTEXT ()
TEMPLATE ()
CUSTOMER_IP_ADDRESS (xx.xxx.xx.xx)
ORDER_ID (12)
CAPTURE_DAY ()
CAPTURE_MODE (AUTHOR_CAPTURE)
STATEMENT_REFERENCE ()
CUSTOMER_PHONE ()
CONFIRM_TEMPLATE ()
BLOCK_ALIGN (center)
BLOCK_ORDER (1,2,3,4,5,6,7,8)
TARGET (_top)

l’idéal est de changer de suite d’hébergeur , si c'est du mutualisé le prix est dérisoire pour un site marchand

Bonsoir,

Changer d'hébergeur est une solution extrémiste et inutile, de plus en plus interdise l'utilisation des fonctions exec(), on sait ce que l'on gagne mais pas ce que l'on perd en changeant. Il y a d'autres solutions.

Quand il vous manque un outil pour bricoler, vous abandonnez ? Moi j'adapte.

A+

Joshua Lindus wrote: Bonsoir,

Changer d'hébergeur est une solution extrémiste et inutile, de plus en plus interdise l'utilisation des fonctions exec(), on sait ce que l'on gagne mais pas ce que l'on perd en changeant. Il y a d'autres solutions.

Quand il vous manque un outil pour bricoler, vous abandonnez ? Moi j'adapte.

A+

Bonjour,

Comme je disais précédemment, il est inutile de précipiter les choses et de baisser les bras avant que tout ait été essayé.

Je suis tombé sur de nombreux posts sur divers forums qui parlaient de l'impossibilité d'utiliser les fonctions exec() et shell_exec() avec certains hébergeurs dont le mien INFOMANIAK NETWORK.

Encore récemment (voir post précédents) on me disait "change d'hébergeur...". Je répondais alors ce que je dis au début de ce message, et inutile finalement d'accuser les hébergeurs s'ils trouvent des solutions.

Après avoir pas mal galéré sur diverses solutions avec des CGI Perl, le temps que j'ai perdu venait surtout de ma méconnaissance du Perl. Pourtant ce langage intéressant à apporté beaucoup au PHP. Il faudra que je m'y plonge un peu plus.

GRACE à INFOMANIAK j'ai pu voir le bout du tunnel. Non pas en autorisant les fonctions interdites, mais en me donnant un bon coup de main pour faire ce sur quoi je n'arrivais pas à finaliser.
J'avais la réponse en PHP mais je m'obstinais sur une autre solution car je n'arrivais pas à retourner une variable depuis Perl.

Donc les gars d'INFOMANIAK ont été SUPER et m'ont fourni le petit plus qui me manquait. Merci donc à eux.

Pour info, il suffit de remplacer l'instruction exec() par un appel HttpRequest vers un script CGI Perl qui renvoie un résultat. Ce qui remplace le $result=exec(....). J'avais le début de la solution mais pas la fin.

Voilà comme quoi en tenant compte des compétences des autres, on arrive à tout, ou presque.

A+