Pas de différence entre cancel_return et normal_return et silentresponse ne marche pas

[CBerty]

Bonjour,

Cela fait plusieurs jours que je bute sur le problème. J'ai lu et essayé pas mal de choses sur le sujet mais rien n'y fait :-(

J'ai fait les tests avec le site en https et http mais ça ne change rien.

Une fois sur la page de paiement de la banque quand je fais "retour boutique" que ce soit pour annuler la commande ou après que le paiement soit bien validé j'arrive sur la même page du site qui me dit que la commande a bien été traitée. En principe en cas d'annulation il me semble que je devrais avoir une page d'erreur de paiement. (par contre dans les commandes Prestashop je vois bien la commande comme annulée)

Et si la transaction se passe bien l'auto-response ne marche pas, la page ne semble pas appelée par la banque.

Quelqu'un a-t-il une piste quelconque ?

Par avance merci.

Prestashop 1.6.1.6 tggatos 4.1.1 Hebergement OVH Performance 1 php 7.0.10 Banque BNP

[TrogloGeek]

Bonjour, il ne s'agit pas ici d'un bug mais plutôt d'un manque de documentation de ma part, désolé ;-)

Vous n'avez pas de page erreur de paiement car vous avez choisi dans la configuration du module de transformer les annulations en commandes avec le statut annulé, le module renvoie donc vers la page de confirmation de commande après avoir créé celle-ci avec le statut annulé, il vous faut ensuite customiser votre page de confirmation de commande pour que celle-ci adapte l'expérience utilisateur au statut de la commande. J'ai choisi ce modus operandi car il s'agit de celui qui a selon moi le plus de chances d'être compatible avec la majorité des modules de suivis statistique comme GAnalytics par exemple.

Cela répond-il à toutes vos questions ?

[TrogloGeek]

J'ai oublié de répondre pour l'auto-réponse : êtes-vous en mode maintenance ? Si oui, avez-vous autorisé les IPs à partir desquelles les serveurs bancaires émettent l'auto-réponse dans la configuration du mode maintenance de PrestaShop ?

Sinon, votre boutique est-elle exploitée via une adresse routable ? S'il s'agit d'une boutique de test sur votre réseau local il est normal que les serveurs bancaires ne puisse la contacter.

Sinon, il s'agit probablement d'un problème avec une règle de réécriture : vérifiez les logs HTTP pour trouver les réponse silentieuses des serveurs bancaires => apparaissent-elles ? si oui, quel est le statut HTTP de la réponse qui leur est envoyée ?

[CBerty]

Merci Damien pour cette réactivité. Merci également pour l'info sur la page erreur de paiement, je vais faire ce que vous m'avez indiqué.

Concernant l'auto-response effectivement, après investigation il apparait que le code http est en 403 dans les logs. Lorsque le firewall de chez OVH (mod_security=security au lieu de mod_security=none dans le fichier .ovhconfig) bloque la réponse de la banque car leur requête ne comporte pas d'entête "User Agent Header"'.

Nous en sommes à chercher comment chez OVH désactiver le mod_security pour une URL particulière ? Ou bien carrément désactiver le pare-feu applicatif d'OVH?

[TrogloGeek]

Il serait bon de se plaindre auprès du service technique bancaire car leur requêtes DOIVENT comporter un User-Agent

[CBerty]

Oui en effet, on va remonter l'info.

Si cela peut servir à d'autres après discussion avec un technicien de chez OVH il m'a conseillé de désactiver leur firewall en me disant que dans notre config (des plus classique) ce n'est pas très utile... Hallucinant !

Et concernant votre idée de configuration de la page confirmation de commande j'ai au final modifié votre fichier /controllers/front/userreturn.php aux alentours de la ligne 70 ou il y a la condition if($order)... qui redirige vers cette fameuse page de confirmation de commande en excluant le statut "annulé". Ce qui donne : if ($order && $order->current_state != 8) ... Du coup en cas d'annulation les internautes sont redirigés vers la page d'erreur paiement du module.

Encore merci.

[TrogloGeek]

Si cela peut servir à d'autres après discussion avec un technicien de chez OVH il m'a conseillé de désactiver leur firewall en me disant que dans notre config (des plus classique) ce n'est pas très utile... Hallucinant !

Je ne connais pas leur règles de filtrage mais je pense que leur pare-feu est utile pour les applications développées from scratch par des amateurs ou équipes de faibles expériences ou parfois juste développées avec une deadline trop courte. Vous seriez probablement surpris du nombre de failles que l'on peut trouver dans de telles applications. Lorsque je gérais le parc d'exploitation en agence web j'utilisais aussi un pare-feu applicatif fait maison qui s'est révélé extrêmement utile pour de nombreux sites dont nous avions récupéré l'hébergement en attendant le développement de leur nouvelle version, des clients qui changeaient de prestataires. S'il n'y avait eu ce pare-feu (et si nous n'avions pas une isolation de sécurité coriace entre chaque site), un bon nombre de ces sites auraient non seulement été piratés mais aussi les autres sites de ces serveurs.

Je pense qu'OVH a de sérieux efforts à fournir en documentation pour ces features récentes, mais je comprends leur choix de l'activer par défaut, se basant sur le fait qu'une équipe technique sérieuse trouverait l'origine du problème et le désactiverait s'il posait problème. Cela dit, à propos de leur documentation, bien que je la trouve trop faible et souvent peu précise, je la trouve largement supérieure à tous les autres hébergeurs avec lesquels j'ai eu à travailler. Malheureusement cela fait partie des marchés qui ont tendance à être nivelés par le bas. La plupart des clients n'ayant qu'une obsession en tête : réduire les coûts récurrents de structure tels que l'hébergement, et ce souvent au prix de frais de maintenance et de reprise d'activité de très loin supérieurs aux économies réalisées...