"erreur appel request" avec module ATOS-SIPS

Bonjour,

ayant récemment migré une boutique VirtueMart vers HikaShop je n'arrive plus à faire fonctionner le module de paiement en ligne ATOS-SIPS pour Sogenactif (qui pourtant fonctionnait bien avec VirtueMart).

J'ai pourtant :

• paramétré le "Dossier de telechargement" dans les préférences du module de paiement : tmp/sips-param/
• ajouté les fichiers "call_autoresponse.php, call_request.php, call_response.php, certif.fr.xxxxxxxxxx, parmcom.xxxxxxxxxx, pathfile, request, response" dans ce dossier (et même dans un sous dossier /b/ car apparemment hikashop le créé automatiquement lorsque le safe_mode est off)
• vérifié les chemins dans tous ces fichiers
• vérifié les droits en execution des fichiers request et response (et des dossiers qui les contiennent)
  (je les ai même retransféré en mode binaire par ftp pour voir si ça venait de ça)

erreur appel request

executable request non trouve /web/xxxxx/www/tmp/sips-param/b/request

Merci beaucoup pour votre réponse, mais ça ne peut pas être ça, puisque j'utilise les mêmes fichiers request et response qu'auparavant (avec le module VirtueMart), et ça marchait sans problème.

J'ai quand même retransféré les fichiers (en mode binaire) pour voir ce que ça donnait (à partir de l'archive sogenactif_p600_PLUGIN_linux-2.6.9.tar) mais j'ai toujours la même erreur.

Le serveur a un kernel 2.6.32.59 et est en 64bits.
J'ai transféré les versions 2.6.9_3.4.2 des fichiers "request" et "response".

Est-ce que quelqu'un aurait une version plus récente de l'API sogenactif ??? car il n'est plus possible de la télécharger en ligne.
Et comment savoir si les executables "request" et "response" sont en 64bits ?

Bonjour,

Etant donné ce que vous dites il ne semble pas y avoir beaucoup d'issus...
L'idée des fichiers en 32bits n'est pas une mauvaise idée, demandez peut être à votre banque de vous fournir des fichiers plus récents et en 64 bits.
Sinon je ne peux que vous conseiller de relire la documentation et de refaire toutes les étapes une à une pour être sur de ne rien louper.
Il est aussi possible que votre chemin d'accès soit trop long (pour le dossier de téléchargent) c'est la raison pour laquelle nous utilisons des noms de répertoires court, un chemin trop long fait crasher l'API.

N'hésitez pas à nous tenir au courant.

eliot wrote: Etant donné ce que vous dites il ne semble pas y avoir beaucoup d'issus...

eliot wrote: L'idée des fichiers en 32bits n'est pas une mauvaise idée, demandez peut être à votre banque de vous fournir des fichiers plus récents et en 64 bits.

eliot wrote: Il est aussi possible que votre chemin d'accès soit trop long (pour le dossier de téléchargent) c'est la raison pour laquelle nous utilisons des noms de répertoires court, un chemin trop long fait crasher l'API.

J'ai du nouveau,
après avoir migré totalement le site sur un autre serveur (1&1), je me suis rendu compte que là tout marchait bien.
Donc, je me suis dit que le problème venait de l'hébergeur.
Et effectivement, NUXIT (l'hébergeur de la boutique) a eu la bonne idée d'installer les binaires "request" et "response" sur ses serveurs :

Les exécutables request et response existent dans le PATH par défaut. Cela signifie que PHP saura les localiser automatiquement, vous n'avez pas besoin de préciser le dossier dans lequel ils se trouvent. Ils sont utilisables de la façon suivante, appelés par la fonction exec de PHP :

exec("request <PARAMS>");
exec("response <PARAMS>");

Bonjour,

En effet c'est peut être un début de solution. Néanmoins notre exec est fait avec un chemin d'accès spécifié (jusqu'au fameux dossier 'b') du coup il devrait logiquement exécuté les fichiers binaires que vous avec uploadés et non ceux du serveur.
Il est possible que ce soit simplement votre hébergeur qui empêche l'execution des binaires... à voir avec eux. Dans tous les cas le problème ne vient pas de chez nous...
N'hésitez pas pour autant à nous tenir au courant de l'évolution de votre situation, cela pourra toujours aider d'autre personne dans votre cas (surtout que la solution SIPS n'est pas vraiment facile à mettre en place )

eliot wrote: Il est possible que ce soit simplement votre hébergeur qui empêche l'execution des binaires... à voir avec eux. Dans tous les cas le problème ne vient pas de chez nous...

Dans un hébergement mutualisé, vous n'avez pas le droit d'exécuter vos propres script, par contre en spécifiant le chemin /home/bin/ dans l'admin de votre Hikashop cela devrait marcher.

Le comportement de Hikashop me semble curieux, malheureusement je ne peux que vous conseiller de contacter l'éditeur de ce software pour savoir comment procéder.

Notre environnement facilite pourtant les choses puisqu'il vous présente le dossier /home/bin dans le PATH par défaut. Donc en exécutant exec("request") et exec("response") vous avez un accès immédiat aux binaires ATOS sans devoir vous préoccuper de où ils sont stockés sur le système... Alternativement vous pouvez spécifier le path explicite : exec("/home/bin/request").

Vous ne pouvez pas installer le certificat dans le dossier /home/bin (sinon il serait visible par tous les clients), vous devez l'installer dans un dossier sur votre FTP. Les fichiers d'exemple ATOS vous montrent comment spécifier le chemin pour trouver le certificat, et j'ose espérer que Hikashop a prévu cette possibilité, sinon il serait difficilement envisageable d'utiliser ce module sur un hébergement mutualisé.

Navré de ne pouvoir vous aider davantage

Bonjour,

Donc si je comprend bien et pour résumer, les exécutables doivent être mis dans le dossier home/bin chez votre hébergeur?
Avez vous essayé d'uploader les fichiers en question dans un dossier /b de ce répertoire en question? Cela devrait au moins régler ce problème.

Pour ce qui est du certificat en revanche c'est un problème.
A vrai dire, je pense que dans votre cas il ne reste que la solution brute à savoir spécifier dans le fichier pathfile un chemin différent pour le certificat.
Vous aurez donc ainsi les binaires et le certificat à deux endroit différents mais le pathfile saura lesquels. Concrètement c'est que le plugin SIPS attend mais nous avons essayé de faciliter les choses et de générer les fichiers automatiquement pour faciliter les vie des utilisateurs. Notamment concernant le problème du chemin trop long.

Bon courage avec cette méthode, n'hésitez pas à nous tenir au courant

eliot wrote: Donc si je comprend bien et pour résumer, les exécutables doivent être mis dans le dossier home/bin chez votre hébergeur?
Avez vous essayé d'uploader les fichiers en question dans un dossier /b de ce répertoire en question? Cela devrait au moins régler ce problème.

eliot wrote: Pour ce qui est du certificat en revanche c'est un problème.
A vrai dire, je pense que dans votre cas il ne reste que la solution brute à savoir spécifier dans le fichier pathfile un chemin différent pour le certificat.
Vous aurez donc ainsi les binaires et le certificat à deux endroit différents mais le pathfile saura lesquels. Concrètement c'est que le plugin SIPS attend mais nous avons essayé de faciliter les choses et de générer les fichiers automatiquement pour faciliter les vie des utilisateurs. Notamment concernant le problème du chemin trop long.