Bonjour à toutes et à tous,
JE suis en abonnement Pro mutualisé , et je rencontre un problème sous prestashop 1.7 avec un module de paiement qui ne marche pas, l'appel ne se fait pas,
j'ai testé sur un autre serveur différent pro mutualisé exactement les même configuration et le module de paiement sa marche
D'où peut provenir le problème d''après vous svp
Cordialement
Hébergement Web-old - Problème avec l'hébergement mutualisé
Related questions
- [RESOLU] Server unable to read htaccess file, denying access to be safe
70955 
24.11.2019 19:11
- Version php 7.0 sur Ovh mais php 5.4.45 sur mon wordpress
65874 10.01.2019 11:14
- Effacer wordpress d'OVH et reinstaller
65142 08.09.2019 21:02
- Comment récupérer son mot de passe phpmyadmin ?
64450 14.11.2016 10:32
- Changer la version d'une base de donnée en mutualisé
61851 22.12.2016 11:46
- Ne supporte pas FTP sur TLS
61646 11.12.2018 18:48
- Résiliation hébergement
61528 27.07.2018 10:39
- Variable upload_max_filesize plus grande que post_max_size
55025 11.06.2017 16:01
- Résiliation hébergement+domaine
53866 11.09.2018 20:28
- Transfert hebergement et domaine .fr entre client OVH ?
52208 21.12.2016 15:10
Bonjour,
Pensez-vous qu'avec la description que vous faites, on peut avoir une idée ?
Bonjour @CHOKRIB1
Quel domaine ?
Quel module de paiement ?
Quelle banque ?
Et surtout, les messages d'erreur dans les log.
Merci pour vos retours
Domaine : souk-orintal .com
Module : ClicToPay SMT (Disponible sur addons)
Système de paiement avec une banque en Tunisie.
Aucun message d'erreur, en mode debug, dans les logs... Rien
le module est en mode test, lorsque je clique pour payer, il reste en boucle dans la page paiement, puis, retourne a l'accueil je reçois un mail de validation.
Pourquoi de mon côté il semble y avoir un problème au niveau serveur.
Car j'ai installé sous le même serveur une version native de prestashop 1.7 et j'ai testé le module, c'est le meme problème
Par contre sous un autre serveur ovh qui a les mêmes configuration, il marche sans problème.
Autre précision, j'avais un module équivalent qui tournait sous prestashop 1.6 depuis 2013. Il y a eu le même problème en aout 2023, aucune solution trouvé, seulement j'ai décidé de migrer vers la presta 1.7 et acheter un nouveau module avec changement de version php de 5.4 vers 7.2,
J'ai testé la 7.4 c'est nul, tout le site ralenti, je suis retourné vers la 7.2
Côté, banque, on me dit qu'il ne reçoivent aucune donnée (vérification dans leur logs) et ne peuvent pas m'aider.
on m'a dit de tester un nslookup via ssh et pointer vers leurs lien, ce n'est pas autorisé il semble en mutulisé, j'ai testé plusieurs site, c'est bloqué chez ovh je ne sais...
Erreur au niveau logs, y a rien de spécifique, pour info, j'ai paypal et aussi module de paiement revolut marche sans problème.
Voila j'espère que c'est pus précis que mon premier poste @Fritz2cat
Bonjour @CHOKRIB1
Faut-il attendre 4 jours entre chaque réponse ? ? ?
Pour paypal et revolut, les adresses IP des serveurs sont-elles bien en Europe ?
Quelle adresse IP de votre site avez-vous donné pour votre banque en Tunisie ?
Bonjour,
1oriental.comoriental.com :
2001:41d0:1:1b00:213:186:33:2
213.186.33.2
cluster002.ovh.net
Votre banque verra l'appel à partir de l'adresse IP 51.68.11.191
certificat SSL: DNS:blog.1oriental.com,oriental.com, DNS:1soukoriental.com,soukoriental.com, DNS:letotebag.com, DNS:1oriental.com,oriental.com, DNS:www.blog.1oriental.com,oriental.com, DNS:www.1soukoriental.com,soukoriental.com, DNS:www.letotebag.com, DNS:www.1oriental.comoriental.com
Vous êtes bien en PHP/7.2 . Ca devient très obsolète.
Bonjour @Gaston_Phone
J'ai bien répondu rapidement, c'es seulement maintenant que ma réponse à été validée.
Je ne comprend pas pourquoi la réponse doit passer par une validation.
L'adresse ip est bien en France, et pour la banque en Tunisie c'est la même adresse mais ca n'a jamais été une contrainte, aucune restriction à ce niveau,
J'ai testé avec un autre serveur Ip française et le test a marché.
Avec php 7.4 il avait une lenteur énorme
Avec la 7.2 le prestashop 1.7.8.9 ca tourne bien.
Bonjour,
J'ai contacté le service monétique, et après vérification, il ne reçoivent aucun appel venant de mon serveur. Sa coince sur OVH.
on m'a dit de tester de faire un appel avec la fonction Curl si vous avez une idée ?
Je ne connais pas les contraintes de votre banque en Tunisie, mais j'ai le souvenir, qu'il y a un an pour le système SUMUP, d'avoir du, pour un site qui avait changé d'adresse de serveur :
- Désinstaller l'application SUMUP et de l'annuler chez SUMUP.
- D'installer à nouveau l'application SUMUP puis de l'activer chez SUMUP.
Ce n'est certainement le même problème, mais cela peut donner une piste.
Bonjour,
il on bien vérifié avec "51.68.11.191" ?
oui si il vous ont donné l'adresse à tester en curl
Cordialement, janus57
Merci pour votre réponse
J'ai trouvé un code a tester en modifiant l'URL de test qu'on m'a communiqué et voilà le résultat
Connection timed out after 5001 milliseconds
Sur le serveur où le module marche voilà le résultat avec le même code
{"errorCode":5,"errorMessage":"Access denied"}
C'est clair qu'il y a un problème niveau ovh non ?
Il s n'ont pas la même adresse IP ?
Quelles sont les adresses IP des Serveurs :
* Celle OK ?
* Celle NOK ?
Quelle adresse IP du serveur de de la banque ?
Quelle est l'adresse IP du serveur à tester en CURL ?
Quelle est l'adresse exacte du fichier à tester avec CURL ?
Bonjour,
ça dépend il faut faire plus de test
Quel est l'URL de test qu'on vous a communiqué ?
Quel est le script que vous avez utilisé ?
Cordialement, janus57
Un délai de 2 à 11 jours entre vos réponses, n'aide pas du tout à la résolution de votre problème..
Apparemment mes réponses doivent être validée avant publication. Là ce n'est pus le cas
je vais répondre a toute vos questions
**Adresse ip serveur non ok :**
Adresse IP de 'www.1oriental.com'oriental.com' : 213.186.33.2
**Adresse ip serveur ok :**
92.222.139.190
Adresse URL a tester : https://test.clictopay.com/payment/rest/register.do
Je n'ai pas d'adresse ip
code que j'ai tester :
> > $ch = curl_init();
> try {
> curl_setopt($ch, CURLOPT_URL, "https://test.clictopay.com/payment/rest/register.do");
> curl_setopt($ch, CURLOPT_HEADER, false);
> curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
> curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 5);
> curl_setopt($ch, CURLOPT_TIMEOUT, 5);
> curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
> curl_setopt($ch, CURLOPT_MAXREDIRS, 1);
> curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);
>
> $response = curl_exec($ch);
>
> if (curl_errno($ch)) {
> echo curl_error($ch);
> die();
> }
>
> $http_code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
> if($http_code == intval(200)){
> echo $response;
> }
> else{
> echo "Ressource introuvable : " . $http_code;
> }
> } catch (\Throwable $th) {
> throw $th;
> } finally {
> curl_close($ch);
> }
> ?>
@janus57
Déjà sans CURL : {"errorCode":5,"errorMessage":"Access denied"}
Le problème serait-il là ?
L'accès est bloqué c'est normal car il manque les paramètres, il s'agit d'une url test qui renvoi une erreur, la réponse se fait deja
Mais dans l'autre serveur on n'a même pas de réponse, c'est bloqué au niveau serveur : **Connection timed out after 5001 milliseconds**
Je n'ai pas trouvé de paramètre idoine dans votre script CURL de test.
Quel serveur ?
Quel est l'URL de test ? ? ?
Serveur qui ne fonctionne pas : J'ai un retour : **Connection timed out after 5001 milliseconds**
=> ce n'est même pas un retour de réponse. La requete ne s'envoi pas.
Le serveur qui fonctionne : **{"errorCode":5,"errorMessage":"Access denied"}** => c'est la réponse du test de la banque, j'ai bien une réponse
Bonjour,
pouvez-vous tester avec ce code : https://gist.github.com/janus57/333b8575d9fc049f9b6771fd452eb7af
Aussi depuis le cluster021 c'est OK et vous indiquez que le cluster028 c'est OK
Au vu de ces infos + le fait que normalement quand OVH faut un blocage c'est sur l'ensemble des mutus.
Avez-vous eu une confirmation à 100% que clictopay ne bloque pas l'IP "51.68.11.191" ?
Cordialement, janus57
Si vous ne donnez pas les bonnes adresses, nous ne pouvons avancer.
Bonjour,
il a donné toute les infos nécessaire pour tester, il a donnée :
- l'url de test
- cluster ou cela fonctionne
- cluster ou cela ne fonctionne pas
- adresse de son site
Cordialement, janus57
Je ne comprends rien.
Il a donné une adresse de clictopay.com : OK
Mais quelle est l'adresse réelle du test qui ne fonctionne pas ?
Merci beaucoup
Voila je viens de tester et c'est le même code erreur
Voici le lien vous pouvez tester :
Serveur problème : https://1oriental.com/info.phporiental.com/info.php
Url de test : https://test.clictopay.com/payment/rest/register.do
Je commence a douter de ca:
> Avez-vous eu une confirmation à 100% que clictopay ne bloque pas l'IP "51.68.11.191" ?
Voila le lien script sur le serveur qui marche https://www.kiatou.tn/info.php
Je pense que l'on ne se comprend pas.
Pour ma part, je propose d'en rester là.
J'espère que @Fritz2cat et @janus57 pourront vous aider à trouver la solution.
Bonsoir.
Merci beaucoup
Et vraiment désolé c'est du Chinois pour moi, j'essai d'expliquer au mieux.
Bonne soirée
Bonjour,
@CHOKRIB1 non vos explications sont bonnes, c'est juste Gaston qui n'a rien compris.
Là actuellement vous devez avoir une confirmation à 100% que clictopay ne bloque pas l'IP 51.68.11.191
Sinon vous pouvez toujours demander au support OVH si il peuvent vous fournir un traceroute depuis le cluster002 à destination de test.clictopay.com mais cela ne va rien prouver car si je fait le test de mon côté depuis un serveur dédié la traceroute s'arrête dans le réseau de Orange Tunisie qui est l'hébergeur de clictopay, ce qui me conforte dans l'idée que clictopay a un système de filtrage en place si il bloque les réponse aux traceroutes.
[code]
root@srv-test01:~# curl https://test.clictopay.com/payment/rest/register.do
{"errorCode":5,"errorMessage":"Access denied"}
~
root@srv-test01:~# traceroute test.clictopay.com
traceroute to test.clictopay.com (196.203.11.80), 30 hops max, 60 byte packets
1 16k.fr.eu6k.fr.eu (5.39.84.253) 0.556 ms 0.734 ms 0.604 ms
2 10.17.81.26 (10.17.81.26) 0.787 ms 0.674 ms 10.17.81.24 (10.17.81.24) 0.492 ms
3 10.73.16.96 (10.73.16.96) 0.385 ms 10.73.16.110 (10.73.16.110) 0.218 ms 10.73.16.98 (10.73.16.98) 0.395 ms
4 10.95.64.0 (10.95.64.0) 1.337 ms 10.95.64.142 (10.95.64.142) 1.228 ms 10.95.64.154 (10.95.64.154) 1.507 ms
5 fra-fr5-sbb1-nc5.de.eu (54.36.50.242) 8.908 ms be104.fra-fr5-sbb2-nc5.de.eu (94.23.122.241) 8.474 ms 8.366 ms
6 be101.1nc5.fr.eunc5.fr.eu (91.121.215.196) 11.025 ms be101.1nc5.fr.eunc5.fr.eu (94.23.122.136) 10.737 ms be101.1nc5.fr.eunc5.fr.eu (91.121.215.196) 11.106 ms
7 be101.mil-kpn-sbb1-nc5.it.eu (91.121.215.195) 17.098 ms 16.966 ms be102.mil-kpn-sbb1-nc5.it.eu (91.121.215.221) 16.851 ms
8 10.200.2.129 (10.200.2.129) 16.733 ms 16.928 ms 16.819 ms
9 orangetunisie.1it.netit.net (217.29.67.92) 43.838 ms * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
[/code]
Cordialement, janus57
Merci beaucoup je vais les contacter encore une fois.
Mais je ne comprend pas il y a plusieurs adresse indifférente de mon côté.
Il y a le serveur et le nom de domaine ? Ils non pas la même adresse ip ?
Car j'ai tester de changer l'adresse ip (géo-localisation) 1 de ip française vers italienne.
La modification à bien été prise en compte mais le problème est toujours présent.
Cet adresse ip qu'il faut donc vérifier s'il est pas black listé chez eux? 51.68.11.191
Bonjour,
vous parlez de vos sites ?
Si oui alors non chaque cluster a sa propre adresse IP de sortie et elle est impossible à changer.
cela ne changera jamais rien, car ce n'est pas cette adresse IP qui va faire les requêtes vers clictopay, c'est l'adresse "passerelle de sortie" qui sert à faire les requêtes et cette adresse est unique par lcutser et surtout inchangeable.
oui conformément à la doc OVH (Cf: https://help.ovhcloud.com/csm/fr-web-hosting-clusters-ip-addresses?id=kb_article_view&sysparm_article=KB0052378)
Note : c'est ce qu'on essaye de vous faire comprendre puis le début avec @Fritz2cat que l'ip qui vous pouvez changer et géolocaliser ne sert à rien pour votre banque car elle ne sert que à recevoir les visiteurs de votre site.
Cordialement, janus57
Bonjour
J'ai contacté le service tecencore une fois de clictopay
On m'indique qu'il s'agit d'un nom de domaine public et aucun blocage de leur côté.
Ils ont eu plusieurs cas avec ovh et la preuve c'est que
J'ai deux hébergements mutualité, deux nom de domaines différents, deux ip différentes et l'interruption des modules était le même jours.
Mais le deuxième est sur cluster010
Bonjour,
Si vous faite un test sur une autre URL cela fonctionne ?
Si oui alors faite un ticket incident auprès de OVH si vous êtes certain.
Cordialement, janus57
Résultat sur cluster013: {"errorCode":5,"errorMessage":"Access denied"}
Résultat sur cluster012: {"errorCode":5,"errorMessage":"Access denied"}
Résultat sur cluster010: Connection timed out after 5000 milliseconds
Résultat du script de @janus57 sur cluster010: Petit script pour tester cURL via un navigateur
Source : https://gist.github.com/janus57/333b8575d9fc049f9b6771fd452eb7af
URL à tester :
(et là j'introduis https://test.clictopay.com/payment/rest/register.do ... et ça tourne , puis Connection timed out after 60001 milliseconds)
Donc OVH fonctionne
Mais cluster010 vers clicktopay c'est bloqué, soit chez OVH, soit chez clicktopay.
Bonjour,
cluster021 pareil
cluster029 pareil
Cela semble trop ciblé pour un blocage OVH (sauf si toutes les requêtes externes du site sont bloquées et là c'est une autre histoire).
Cordialement, janus57
Non non, j'ai essayé d'autres URL, avec succès
Bonjour,
je pensez plus au site de @CHOKRIB1 car j'ai pas vu de réponse à ma question qui demander de tester sur d'autres urls (et j'ai pas vu de lien pour tester le script).
Cordialement, janus57
Bonjour
Merci beaucoup.
Qu'est ce que vous me conseillez de tester pour cible plus le problème ?
@Fritz2cat
A problème précis, question précise:
est-ce clicktopay bloque les connexions qui proviennent de 51.68.11.211 ?
Ils disent que non mais les réponses copiées ici ne sont pas si précises, et ils me semblent tourner autour du pot.
Ce genre de question nécessite une réponse en un mot: **OUI** ou **NON**.
Ceci ne veut rien dire:
Bonjour,
perso grâce à @Fritz2cat qui m'a mis le script a dispo sur le cluster010 je viens de tester pas mal d'IP de clicltopay et **TOUS** sont inaccessible et si c'est un autre client dans le même range IP bah là tout à coup ça fonctionne.
[code]
root@srv-test01:~# host test.clictopay.com
test.clictopay.com has address 196.203.11.80
root@srv-test01:~# host ipay.clictopay.com
ipay.clictopay.com has address 196.203.11.82
[/code]
Je pense de plus en plus que clictopay se foutent de vous et qu'il y a bien un blocage mais sur le range complet de clictopay donc peut être au niveau de leur opérateur réseau directement.
**EDIT :**
exemple concret, si on fait un curl sur 196.203.11.226 (ce qui en url donne **https:// mail[point.]landor[point.]com[point.]tn/owa/**) le curl arrive bien à passer et on est plus chez clictopay mais on reste dans le même range IP opérateur (196.203.10.0/23)
Cordialement, janus57
Je viens de tester directement avec les techniciens de monétique en vérifiant de leurs côté tout blocage dans leur serveur venant de mon ip
il y a rien qui arrive chez eux
On me dit de vérifier avec OVH pour qu'elle raison je n'arrive pas a pointer vers 192.203.11.82
OVH ne me répond jamais
Cette adresse n'est pas joignable. C'est normal.
NetRange: 192.203.11.0 - 192.203.11.255
CIDR: 192.203.11.0/24
NetName: EXECNET4
NetHandle: NET-192-203-11-0-1
Parent: NETBLK-EXECNET (NET-192-203-8-0-1)
NetType: Reassigned
OriginAS:
Organization: State of Texas, Office of the Governor (STOG)
Bonjour
Je reviens vers vous après une longue bataille entre monétique et ovh, à chaque fois des jours d'attente de réponse et chaqu'un renvoi la balle.
Voici la dernière réponse de monétique :
On a détecté le problème ses c'est au niveau de votre hébergeur, ci-dessous la trace des appels en provenance de votre environnement et c'est détecté comme malicieuse
Merci de demander à votre hébergeur de prendre les mesures nécessaires afin de vérifier cela
Alors qu'en pensez vous? Ovh pourra régler ce problème?
Merci
Bonjour,
C'est fou, j'avais prédit que le blocage était chez eux...
De mon point de vue OVH ne fera pas grand chose car c'est visiblement une blackliste spécifique à Fortigate et qui est maintenu par Fortigate.
Cordialement, janus57
Si cette trace vous a été remise par clictopay ou leur fournisseur Agence Tunisienne Internet ou orangetunisie.tn, c'est que la connexion sort bien de OVH, et il faut arrêter de chercher du côté Nord de la Méditerranée.
Je ne comprends pas "_On a détecté le problème ses c'est au niveau de votre hébergeur_". Qui a dit ça ?
Bonjour,
pour moi cette trace c'est celle de leur firewall qui doivent louer avec leur connexion (et serveurs?) chez Orange Tunisie.
Donc pour moi ils ont la possibilité de laisser passer 51.68.11.191 à travers le blocage s’il le souhaite réellement.
Cordialement, janus57
C'est les technicien de monétique.
Ce n'est pas à ovh d'enlever cette menace.
C'est comme si mon ip est déclaré malveillante non ?
Chacun déclare ce qu'il veut. Le petit-fils du jardinier de ma voisine a dit que gouv.fr était hostile. Devez-vous le croire ?