Hikashop et parefeu OVH : invoice pdf

  • Posts: 53
  • Thank you received: 6
  • Hikashop Business
2 years 1 week ago #340888

-- HikaShop version -- : 4.5.1
-- Joomla version -- : 4.1.2
-- PHP version -- : 7.4.25
-- Browser(s) name and version -- : Firefox 99.0

Bonjour,
Nous recevons généralement trois mails par commande effectuée : commande crée, notification de paiement et commande confirmé avec en PJ la facture au format pdf.
Ce matin nous recevons de la part de Paypal l’habituel mail « PayBox system (compte rendu de telecollecte) » qui nous indique le paiement d’une commande OK alors que nos avions reçu juste le mail commande crée hier pensant que le client n’était pas allé jusqu’au bout…

Sur le back -end Hikashop la commande est bien annoncé comme confirmée. Test dans configuration générale Joomla « Envoi email PHP mail » tout est OK.
On fait une commande test et le problème se confirme : réception, uniquement du mail « commande crée »

Au passage impossible via l’interface de réediter le pdf avec ce message d’erreur « unable to get the size of the image » voir screenshot ci dessous :



On se dit que le pb vient peut être de OVH et de son pare-feu. Nous avions désactivé le pare-feu applicatif dans les options PHP (voir pb pour passage à PHP8 ici : www.hikashop.com/forum/5-support-en-fran...utualise-paybox.html ) mais pas l’option pare-feu dans le multidomaine...

Au sujet de ces pares-feu OVH il semble qu’il y ait un pb avec Joomla et mode apache "ModSecurity" activé par le parefeu. Doc OVH ici docs.ovh.com/fr/hosting/activation-pare-feu-applicatif/
Visiblement sur modsecurity, une règle dit que chaque url ne doit pas contenir plus de 4 [] imbriqués. Et certains composant joomla en ont 6 ou 7...
Plus d’infos ici www.hikashop.com/forum/checkout/903787-p...ion-de-commande.html

En désactivant également le pare-feu ( ce matin) dans la partie multidomaine de l’interface OVH et en refaisant un test de commande "Alléluia" cela refonctionne normalement : réception des trois mails avec la facture en PJ.

On en déduit que Ovh a probablement changé ses paramétrages dans la journée d’hier car il y deux jours avec la même configuration tout était ok. Aucune modif sur le site de notre part...

Donc bien penser à désactiver sur OVH les deux options de pare-feu qui sont incompatibles avec Hikashop/Joomla 4 depuis hier seulement...sauf erreur de notre part.

Tout fonctionne sauf que si, à partir de l’interface Hikashop, on essaye de réediter la facture au format pdf on obtient un nouveau message d’erreur qui indique cette fois çi « TCPDF error some data has already been output, can’t send pdf file »…

Une solution pour régler cela ?

Merci d’avance.
Ps : merci de déplacer ce message dans la section "support en français"

Attachments:
Last edit: 2 years 1 week ago by GARANDET. Reason: Erreur de section forum. Ce message devrait être dans la section support en français

Please Log in or Create an account to join the conversation.

  • Posts: 81539
  • Thank you received: 13069
  • MODERATOR
2 years 1 week ago #340891

Bonjour,

Encore une fois, je ne vois pas le lien entre cette erreur et le blocage des requêtes HTTP avec des [] dans les paramètres.

Normalement, l'erreur "unable to get the size of the image" indique que l'URL d'un des tags img de la facture est invalide ou inaccessible. C'est souvent le cas lorsqu'il y a une erreur dans l'URL, bien sûr, mais également si votre serveur n'a pas le droit de faire des requêtes HTTP. C'est le cas si allow_url_fopen est désactivé dans le php.ini. Donc c'est la première chose à vérifier. Et si c'est déjà bon de ce coté là, alors il y a quelques chose d'autre qui bloque sur le serveur / parfeu pour la récupération de l'image, mais difficile à dire quoi spécifiquement de notre coté. C'est quelque chose à voir du coté d'OVH. Apparemment, vous n'êtes pas le seul avec ce genre de problématique chez OVH:
community.ovh.com/t/allow-url-fopen-lire...et-contents/47012/26

Concernant l'erreur « TCPDF error some data has already been output, can’t send pdf file », c'est plus difficile de répondre. Cela indique qu'il y a des du texte qui a été envoyé au navigateur et à cause de cela, TCPDF (la librairie qui génère le PDF) ne peut pas envoyer le PDF au navigateur.
Donc toute la question est de savoir qu'est ce qui envoi du texte au navigateur avant cela.
Cela peut potentiellement venir de n'importe quel fichier PHP sur le site.
Le mieux est de faire un test :
- éditez le fichier plugins/hikashop/attachinvoice/vendor/tecnickcom/tcpdf/tcpdf.php et juste après la ligne

public function Output($name='doc.pdf', $dest='I') {
rajoutez
exit;
- recliquez sur le bouton pour récupérer un PDF dans le backend et dans la popup, vous aurez le texte qui est envoyé au navigateur avant que TCPDF puisse envoyer le PDF.
Il est fort probable que cela soit un warning ou une notice qui est affichée du fait de l'activation de l'error reporting dans la configuration Joomla. En mettant cette option à "none" cela cacherait les warnings/notices et donc résoudrait le problème. Mais idéalement, il faudrait corriger ces warnings / notices.
Après, il est possible que cela vienne d'autre chose également. difficile à dire sans savoir ce qui est envoyé au navigateur.

Please Log in or Create an account to join the conversation.

  • Posts: 53
  • Thank you received: 6
  • Hikashop Business
2 years 1 week ago #340900

Bonjour Nicolas,
Merci pour cette réponse détaillé et précise, c'est vraiment appréciable.
Concernant mon précédent propos Visiblement sur modsecurity, une règle dit que chaque url ne doit pas contenir plus de 4 [] imbriqués. Et certains composant Joomla en ont 6 ou 7..., il s'agit d'une citation trouvé sur le forum Joomla. Cela dépasse mes compétences, je l’ai juste rapporté ici au cas ou cela vous serve....
Pour mon problème de ne pouvoir récupérer la facture pdf : effectivement le rapport d’erreur était réglé sur maximum mais sans signalement sur le front end, ni ailleurs ; donc sans pb dans mon esprit. Il avait été activé suite aux bugs lié au cache de Joomla (courant février), j'avais oublié de remettre à "non par défault".
En désactivant le rapport d’erreur et via la back end HS il est à nouveau possible de générer une facture d'une commande passé. Donc mon problème semble résolu.
J’ai néanmoins testé la modification suggérée sur le fichier plugins/hikashop/attachinvoice/vendor/tecnickcom/tcpdf/tcpdf.php
Cela bloque la génération de la facture pdf avec une pop up blanche….Je ne sais pas ce que cela signifie !
Voir screenshot ci dessous :


Pour résumer et dans mon cas :
- il ne faut pas activer les pares feu OVH (ni applicatif PHP ni multisite) au risque de ne pas recevoir les notifications de commandes par mail.
- l’activation des rapport d’erreurs serveur dans la config Joomla bloquait la génération, après commande via le back end HS, de la facture pdf.

Merci en tout cas mon pb semble résolu.

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 81539
  • Thank you received: 13069
  • MODERATOR
2 years 1 week ago #340902

Bonjour,

Bizarre que le exit ne fourni pas de texte. Avez-vous rajouté le exit tout en laissant le "error reporting" sur maximum ? Car si vous avez désactivez le error reporting, alors forcément, il n'y a plus d'erreur avant et donc il est normal que la popup soit blanche.

Après, vu que vous confirmez que cela ce résoud en désactivant l'error reporting, cela indique bien que le souci vient d'un warning ou d'une notice (voir d'un "deprecated"). Et normalement ces messages sont loggés dans le PHP error log du serveur. Donc il devrait être possible de retrouver le souci dans ce log, même avec l'error reporting désactivé dans la configuration Joomla.

Please Log in or Create an account to join the conversation.

  • Posts: 53
  • Thank you received: 6
  • Hikashop Business
2 years 1 week ago #340918

Bonjour,
Dans les logs OVH section "error" j'ai ce message pour la journée d'hier (ou ce sont produit no difficultés décrite ci dessus en rapport avec la re-edition de la facture pdf depuis le back-en HS)

Log section "error"14/04 :

[Thu Apr 14 11:06:47 2022] [error] [client 138.246.253.24] [host flying-puydedome.net] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace.

Log section "web" 14/04 :

31.210.20.124 flying-puydedome.net - [14/Apr/2022:06:35:31 +0200] "GET / HTTP/1.1" 301 248 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36"
31.210.20.124 www.flying-puydedome.net - [14/Apr/2022:06:41:41 +0200] "GET / HTTP/1.1" 301 248 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36"
149.202.78.60 flying-puydedome.net - [14/Apr/2022:09:30:33 +0200] "GET / HTTP/1.1" 301 248 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0"
20.115.17.246 www.flying-puydedome.net - [14/Apr/2022:10:10:49 +0200] "GET / HTTP/1.1" 200 738 "-" "python-requests/2.27.1"
145.239.143.55 flying-puydedome.net - [14/Apr/2022:10:39:06 +0200] "GET / HTTP/1.1" 301 248 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0"
145.239.143.55 flying-puydedome.net - [14/Apr/2022:10:41:50 +0200] "GET / HTTP/1.1" 301 248 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0"
138.246.253.24 flying-puydedome.net - [14/Apr/2022:11:06:47 +0200] "GET /robots.txt HTTP/1.1" 500 544 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.146 Safari/537.36"
34.73.162.22 flying-puydedome.net - [14/Apr/2022:19:07:23 +0200] "GET /wp-login.php HTTP/1.1" 301 260 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"
95.73.239.37 flying-puydedome.net - [14/Apr/2022:19:16:59 +0200] "GET / HTTP/1.1" 301 248 " flying-puydedome.net/ " "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36"
85.208.22.181 flying-puydedome.net - [14/Apr/2022:22:22:24 +0200] "GET / HTTP/1.1" 301 248 "-" "CATExplorador/1.0beta (sistemes at domini dot cat; domini.cat/catexplorador/ )"
194.38.20.161 flying-puydedome.net - [14/Apr/2022:23:21:37 +0200] "GET /public/plugins/elfinder/connectors/php/connector.php HTTP/1.1" 301 300 "-" "ALittle Client"

Du chinois pour nous mais cela veut peut être dire beaucoup pour vous?

Sinon effectivement on a du faire l'exit (sur le fichier plugins/hikashop/attachinvoice/vendor/tecnickcom/tcpdf/tcpdf.php) en ayant bêtement remis le report erreur à non au lieu de maximum. Si ce les infos ci dessus ne sont pas suffisantes, on refera le test exit avec le report d’erreur sur maximum la semaine prochaine mardi ou mercredi...
Ps : notre hébergement OVH se nomme ndd.net mais notre site est sur le .fr je ne pense pas que cela soit la source de nos pb?

Merci

Last edit: 2 years 1 week ago by GARANDET.

Please Log in or Create an account to join the conversation.

  • Posts: 81539
  • Thank you received: 13069
  • MODERATOR
2 years 1 week ago #340922

Bonjour,

Le premier log, c'est le log d'erreur du serveur web. Le second log c'est le log d'accès du serveur web.
Donc aucun des deux n'est le log d'erreur PHP. Ce doit être un autre log encore. Là aussi, le support d'OVH pourrait vous indiquer où trouver le log d'erreur PHP, car cela dépend de comment le serveur est configuré donc je ne peux pas le dire vu d'ici.

Difficile de dire quoi que ce soit sur l'erreur sans avoir le message d'erreur.

Please Log in or Create an account to join the conversation.

Time to create page: 0.085 seconds
Powered by Kunena Forum