Bonjour,
J'essaye actuellement de mettre en place des tests pour mon API.
Pour cela j'utilise PhpUnit et GuzzleHttp.
Lorsque j'essaye d'appeler une url sur mon domaine ovh (https://domaine.com/fonction) la connexion est refusé.
Si j'essaye de le faire par localhost (https://localhost:443/fonction) la connexion ne s'arrete pas sans donner de réponse.
Est-ce qu'il existe une sécurité qui pourrait m'empecher de faire des appels localhost par Curl ?
J'utilise un Mutualisé Pro avec PHP est en version stable64 - 8.0 donc je ne pense pas que php soit le problème ici.
Merci d'avance pour votre aide,
Mathieu.
Curl Connexion refusée sur localhost
Related questions
- Connexion à mon compte client
152376
13.02.2019 09:51
- Serveur non sécurisé, celui-ci ne supporte pas FTP sur TLS
126017
03.09.2018 14:46
- reCAPTCHA erreur pour le propriétaire du site : clé de site non valide
110345
14.02.2019 16:17
- [FAQ] Comment mettre à jour mon site pour supporter Apache 2.4 ?
97774
28.07.2017 11:39
- Passage en php 7.4
96868
30.06.2020 05:05
- Augmenter taille PHP Post Max Size sur mutualisé ?
91161
04.12.2019 21:52
- The requested URL / was not found on this server
90378
02.03.2017 18:25
- Deploy d'un projet Node JS
90340
12.10.2016 20:18
- NextCloud sur mutualisé
90244
07.04.2017 08:42
- Ce site est inaccessible Impossible de trouver l'adresse DNS du serveur
89974
16.10.2016 16:24
Bonjour,
sur les mutus, il n'y a pas de localhost.
Il y a diverses protections sur les mutus, qui ont souvent été mises en place suite à des abus, des individus malveillants qui utilisent les mutus comme plateforme pour lancer des attaques.
En réaction OVH ferme les robinets, de manière un peu au coup par coup ; et la documentation à ce sujet est inexistante.
Merci pour votre réponse,
Je peux donc abandonner l'idée d'appeler directement locahost.
Mais c'est étrange que, depuis mon mutualisé, je ne puisse pas contacter une url d'un de mes domaines ?
Le but étant de réaliser les tests des urls de l'API directement sur le même hebergement.
Merci encore pour votre aide,
Mathieu.
En fait les hébergements sortent les requêtes sur une autre adresse IP que les connexions entrantes.
Vous devez toujours utiliser le nom de domaine et rien d'autre pour les appels à des pages ou scripts sur les hébergements OVH.
Mais comme je le disais il y a des protocoles et des plages d'adresses bloquées en sortie, et je n'ai jamais trouvé la moindre documentation à ce sujet.
Qu'entendez vous par "adresses bloquées en sortie" ?
Car les appels curl fonctionnent dans l'ensemble sur des domaines qui ne m'appartiennent pas (Aussi hébergé chez OVH) mais le domaine cible (Il m'appartient et est donc relié au même compte OVH que le mutualisé) lui ne fonctionne pas.
Pouvez-vous dévoiler ce nom de domaine ?
Effectivement, désolé, je ne l'avais pas donné: https://karookie.app
Donc si je comprends bien, votre site hébergé sur l'hébergement cluster031 n'a pas accès à l'hébergement lui-même via le port 443/tcp ? Seul OVH pourrait répondre à cette question précise.
Oui c'est effectivement cela. Même chose via le port 443.
Je vais me tourner vers OVH directement alors.
Merci tout de même pour votre aide :).
Petit UP:
Dans un script php (exemple.php) de test j'ai ajouté l'appel CURL en question:
- Si j'essaye d'accéder à exemple.php par le navigateur -> La connexion curl fonctionne.
- Si j'essaye de lancer le script exemple.php avec phpunit (c'est à dire en commande) -> Failed to connect to karookie.app port 443: Connection refused .
Je suis un peu dépassé par ce résultat. Est-ce que ça peut-etre un problème de droit ? Pour rappel le problème est sur un mutualisé.
Merci pour votre aide.
Bonjour,
un script php lancé depuis un navigateur ou depuis le shell ne s’exécutera pas dans le même environnement.
Pour moi ce que vous cherchez à faire en shell ne fonctionnera pas à cause des restrictions OVH.
Cordialement, janus57
Bonjour,
Merci pour votre réponse.
C'est effectivement possible, mais pour quelle raison ?
Il n'y a pas de différenc, dans mon cas, entre l'execution d'un script par php (par navigateur) et par shell.
Si c'est une question de sécurité les deux devraient ne pas fonctionner..
Je reste en attente de la réponse du support OVH et je vous informerai de la raison exacte.
Bonjour,
si, c'est pas le même environnement.
Le shell a beaucoup plus de restrictions car par le passé des petits malin c'était amusé à faire des rebond via SSH pour attaquer l'infra OVH avec l'infra OVH.
Cordialement, janus57