HIKASHOP ESSENTIAL 60€The basic version. With the main features for a little shop.
HIKAMARKETAdd-on Create a multivendor platform. Enable many vendors on your website.
HIKASERIALAdd-on Sale e-tickets, vouchers, gift certificates, serial numbers and more!
MARKETPLACEPlugins, modules and other kinds of integrations for HikaShop
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>";
}
Please Log in or Create an account to join the conversation.
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+
Please Log in or Create an account to join the conversation.
