Erreur retour Paybox

Bonjour Valérie,
Merci de ta réponse.
J'ai réalisé hier plusieurs tests en mettant des traces dans certains php du plugin pour comprendre ce qui se passe.
Je suis tout à fait d'accord avec toi sur le fait que le plugin Hikashop n'est pas sécurisé car il conserve la clé en clair dans la base de données et que la solution utilisée dans ton développement est bien plus sûr avec une clé conservée cryptée. C'est aussi pour cela que nous avons choisi virtuemart pour le site sur lequel je travaille.
Par contre, j'ai pu constater que le traitement réalisé pour calculer la clé HMAC est le traitement natif proposé par paybox (passage en binaire puis génération HMAC avec SHA512), autant dans le plugin Hikashop que dans celui que tu as développé, soit dans ton développement (paybox/paybox/helpers/paybox.php) :

private function generateHMAC ($msg, $payboxKey) {
$binKey = pack("H*", $payboxKey);
$hmac = strtoupper(hash_hmac($this->getHashAlgo(), $msg, $binKey));
return $hmac;

Cette fonction est elle-même appelée par la fonction
function getHmac ($post, $payboxKey) {
$msg = '';
$msg = $this->stringifyArray($post);
$hmac = $this->generateHMAC($msg, $payboxKey);
return $hmac;
}

Si je remplace la variable $payboxKey dans la commande "generateHMAC par une variable chargée en ASCII avec la valeur reçue de paybox (en dur), le traitement fonctionne normalement et j'affiche l'écran paybox pour valider mon achat. Cela voudrait dire qu'il faudrait sans doute repasser le format de la clé cryptée conservée dans la base en ASCII juste avant le traitement de génération HMAC.

Je suppose que ce décryptage existe quelque part dans les traitements puisqu'en prenant l'écran d'édition des paramètres du plugin avec firebug, la valeur affichée avec une suite *********** contient bien la valeur ASCII saisie initialement et non celle conservée dans la BDD.

Fais-je une erreur de raisonnement ou ceci est-il du à un traitement existant mais non résolu (je me souviens de ton message concernant la fonction parse_ini_file éventuellement désactivée, mais je ne trouve pas cette fonction dans les environnements concernés (synology en local, LWS ou OVH en ligne). Je te joins un fichier avec les extensions proposées par mon serveur local, ainsi que la configuration php LWS.

A ta disposition en message public ou privé sur le sujet. Je peux être disponible pour en parler de vive voix si cela permet d'avancer sur le sujet (retraité et autoentrepreneur).

Merci d'avance de ton avis sur le sujet.

Bonjour

Par contre, j'ai pu constater que le traitement réalisé pour calculer la clé HMAC est le traitement natif proposé par paybox

ben oui, il n'y a pas tellement le choix. L'algorithme de generation du HMAC qui doit être envoyé à Paybox doit être le même que celui de Paybox. La sécurité ne reside pas la. Elle reside dans le fait que la clé de Paybox qui est sauvegardée dans la BDD est encryptée, et que la clef VM qui encrypte la cle Paybox est dans un fichier à part hors de l'espace web.
Cette fameuse cle VM n'est pas dans la BDD sinon c'est comme fermer sa maison à clef, et mettre la clef sous le paillasson

Ce que tu as fait, ne sert pas à grand chose. Désolée.

Fais cela plutôt:

va dans le fichier paybox.xml, et change temporairement ca:


<field name="key" class="vmwarn required" type="password" size="200" maxlength="200"

<field name="key" class="vmwarn required" type="text" size="200" maxlength="200"

va dans la config du paiement de paybox dans vm

- si ce qui est affiché est correct, alors cela veut dire que tu as peut être le meme pb que clef2web: vérifie que ton chemin est bien un chemin absolu

- si ce qui est affiché n'est pas bon, alors il y a un pb au niveau du cyrptage /decryptage de la clef. donc la il faut investiguer plus. Mais c'est impossible pour moi en lisant ton phpinfo de deviner ce qui se passe.

ooops.. j'avais pas bien lu cette partie

Je suppose que ce décryptage existe quelque part dans les traitements puisqu'en prenant l'écran d'édition des paramètres du plugin avec firebug, la valeur affichée avec une suite *********** contient bien la valeur ASCII saisie initialement et non celle conservée dans la BDD.

oui exact

en fait ce que je te demande de faire, c'est ce que tu as deja compris

donc ta cle est correctement cryptée / decryptée dans l'administration

donc si elle n'est pas decryptée coté visiteur vérifie ton chemin 'Chemin vers les médias de produits à vendre'

Valérie,

Mon chemin vers les produits à vendre est bien saisie en valeur absolu :
/volume1/web/safe_cyclobout/ sur mon serveur de test donc en dehors de l'arborescence de mon ste
ou
/htdocs/cyclobout en production (je n'ai pas accès à la racine hors de mon arborescence site chez LWS)

Le résultat reste identique ce qui est logique puisque l'appel à la fonction de génération du hmac utilise toujours la clé cryptée issue de la basse de données et non sa valeur ASCII (vérifié avec une trace "Echo" avant l'appel. Sais-tu me dire où la clé devrait être décryptée avant cet appel, ce qui me permettrait d'essayer de tracer ce qui se produit ou as-tu une autre idée de ce qui pourrait se produire ?.

Je te confirme par ailleurs qu'en passant en mode "text" le champs de la clé saisie dans l'écran de paramètrage, la valeur affichée est bonne (ce que m'avait déjà donné la lecture du contenu du chams via firebug).

Valérie,

La situation s'est débloquée en pre-production et en production avec le chemin relatif. Peut-être un problème de cache dans l'intervalle pour expliquer mon message précédent. Je laisse encore la question ouverte avant validation définitive mais je crois que tout est bien.

Bonjour,
Bonne nouvelle