Déclencheur webhook de mass action

-- HikaShop version -- : 6.5.2
-- Joomla version -- : 6.1.3
-- PHP version -- : 8.3

Bonjour,
tout d'abord je tiens à préciser que ce retour à été écrit à l'aide de Claude IA.

HikaShop 6.5.2, Joomla 6.1.3, PHP 8.3, LiteSpeed. Le déclencheur « On HTTP request (webhook) » d'une mass action sur la table order rencontre trois problèmes.

hikashopmassaction.php ligne 357 compare l'endpoint à $_SERVER. Avec la réécriture d'URL SEF standard, PATH_INFO est vide et l'endpoint renvoie un 404 Joomla. Il faut appeler /index.php/mon-endpoint au lieu de /mon-endpoint, ce que l'aide à l'écran ne laisse pas deviner.

Ligne 366, la vérification fait $headers sur le retour de getallheaders(), sans repli sur $_SERVER ni sur $_GET — contrairement à la branche MCP lignes 236-238 qui, elle, les prévoit. Sous LiteSpeed, la clé n'est jamais reconnue.

Une fois l'authentification passée et « Load element data » coché, l'exécution échoue sur SQL 1146 : Table 'xxx_hikashop_' doesn't exist — le suffixe de table est vide, le contexte n'est pas transmis dans cette branche.

Cordialement,
Nicolas

Bonjour,

Merci pour ce rapport, les trois points sont confirmés, reproduits ici et corrigés. Ils partaient tous du même bout de code et se cumulaient.

Pour le chemin : c'est bien PATH_INFO qui était lu, et il est vide dès que la réécriture d'URL de Joomla est active. L'aide à l'écran annonce pourtant l'adresse sans index.php, donc c'est le code qui avait tort, pas l'aide. Les deux adresses fonctionnent maintenant, avec ou sans réécriture, et cela vaut aussi pour l'adresse du point d'entrée MCP qui avait exactement la même limite.

Pour la clé : au delà de l'absence de repli, le tableau rendu par getallheaders() garde la casse envoyée par le client, et la lecture était faite sur la casse exacte "X-API-KEY". Un client envoyant "X-Api-Key" était donc refusé, ce que nous avons reproduit sur Apache, ce n'est donc pas propre à LiteSpeed. Toute casse est acceptée désormais, avec un repli sur $_SERVER quand getallheaders() n'existe pas. La comparaison se fait aussi à temps constant, et la clé n'est plus recopiée dans le journal.

Pour le SQL 1146 : la variable qui porte le nom de la table n'était affectée qu'à l'intérieur du bloc qui traite le paramètre de tri, et elle était utilisée en dehors. Sans paramètre "order" dans la requête, le nom de table partait vide. En passant ?order=une_colonne la requête aboutissait. C'est maintenant corrigé.

Un point sur votre chemin d'endpoint : il doit commencer par une barre oblique, /mon-endpoint et non mon-endpoint, sinon la comparaison échoue et vous obtenez un 404 même une fois le reste corrigé.

Téléchargez le paquet d'installation d'HikaShop sur notre site et installez-le sur le votre pour avoir les différents patchs.