Allow_url_fopen : lire URL externe avec fonction PHP file_get_contents()

Cependant, la fonction PHP file_get_contents() semble verrouillée lorsqu'on appelle une URL externe, alors que la directive "allow_url_fopen" est bien à "On" dans le php.ini.

Bonjour @MaximeR22

De mémoire cette fonction pour lire une page sur un serveur externe à OVH.

@Gaston_Phone
Merci pour votre retour, mais de quelle fonction parlez-vous ?

Quelle erreur as-tu ?
As-tu testé en mode Web en plus du CLI PHP ? (ces 2 environnements PHP sont différents chez OVH)

Merci pour votre retour, mais de quelle fonction parlez-vous ?

Je me suis trompé.

Je parlais en fait de lire une page sur un serveur externe à OVH.
C'est une autre fonction.

Je n'ai utilisé la fonction PHP file_get_contents() que pour lire le contenu d'un fichier déjà mis sur mon hébergement OVH.

```text @ManuelD1
Oui, testé en mode web au départ, et debug en CLI.

Même problème avec les 3 méthodes ci-dessous :
- CLI : sortie vide
- Mode web : "Warning: file_get_contents(https://serveur-distant.com/path/file.xml): failed to open stream: Connection refused"

$url = 'https://serveur-distant.com/path/file.xml';

// METHODE 1
$xmlContent = file_get_contents($url);

// METHODE 2
try {
$opts = ['http' => ['user_agent' => 'Mozilla/5.0']];
$context = stream_context_create($opts);
$xmlContent = file_get_contents($url, false, $context);
} catch (\Exception $e) {
echo $e->getMessage();
}

// METHODE 3
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$xmlContent = curl_exec($ch);
curl_close($ch); ```

J'allais justement te proposer de tester un CURL...
Bizarre effectivement, car sur un Mutu Perf, je fais aussi du file_get_contents et du CURL sur des URLs externes et ceci sans problème.
Peut-être un blacklistage du côté du serveur de destination ?

@ManuelD1
Non, aucune restriction sur le fichier cible.
J'ai vérifié en testant sur un fichier sur mon propre serveur, en local puis avec l'URL absolue.

// OK : contenu affiché
php -r "echo file_get_contents('path/file.xml');"

// ERREUR : sortie vide
php -r "echo file_get_contents('https://1serveur.com/path/file.xml'serveur.com/path/file.xml');"

Alors que le contenu de l'URL https://1serveur.com/path/file.xmlserveur.com/path/file.xml est bien visible via un navigateur.

@ManuelD1
Ça me rassure déjà que ce soit possible avec ce type d'hébergement mutualisé, j'avais peur de devoir changer d'offre juste pour ça.

J'ai aussi vérifié que l'extension cURL était bien chargée, c'est OK :

php -r "echo function_exists('curl_version') ? 'OK' : 'Erreur';" // --> "OK"
php -r "var_dump(extension_loaded('curl'));" // --> "bool(true)"

@Gaston_Phone
La fonction file_get_contents() peut effectivement interroger une URL externe à condition que allow_url_fopen=On dans le php.ini, ce qui est bien le cas.
Mais j'ai le même souci en cURL aussi sur ce serveur, alors que le même code fonctionne bien depuis un autre serveur.
Donc j'ai l'impression que le problème semble être une restriction similaire à allow_url_fopen pour les URL externes

Je sèche...
J'utilise file_get_contents, entre autres, pour le recaptcha V3 de Google.
Peux-tu tester son API ? pas besoin de récupérer une clé, tu auras une erreur, mais dans un vrai retour JSON : https://www.google.com/recaptcha/api/siteverify

@ManuelD1
Même problème... :(
Le retour JSON s'affiche bien quand je teste en local depuis mon ordi :

$ php -r "echo file_get_contents('https://www.google.com/recaptcha/api/siteverify');"
{
"success": false,
"error-codes": [
"missing-input-secret"
]
}

Mais depuis mon serveur, le retour est toujours vide.
Il y a bien un souci avec les URL externes mais je ne comprends vraiment pas pourquoi.

Tu devrais ouvrir un ticket auprès du support pour qu'ils vérifient si le cluster où se trouve ton hébergement n'a pas un problème sur les accès externes.
Je viens de tester, sur le cluster 002 où je suis, tout est OK.
Ou sinon, si quelqu'un de la Team OVH passe par ici.

@ManuelD1
Oui c'est ce que j'ai fait, en leur indiquant le lien de cette discussion pour info.
Merci pour ton aide en tout cas

J'ai beau chercher dans toutes les directions, je ne vois pas toujours pas pourquoi le file_get_contents() bloque sur les URL externes.

J'ai retesté avec cette commande :
php -r "echo file_get_contents('https://www.google.com/recaptcha/api/siteverify');"

Le contenu JSON s'affiche bien quand je l'exécute depuis mon ordi en local, et aussi depuis un autre serveur OVH (Cloud Web, cluster 024), mais toujours pas depuis mon serveur Performance (cluster 028).

J'ai aussi essayé de désactiver le firewall depuis le manager OVH, section "Multisite", mais ça ne change rien.

@Gaston_Phone, @ManuelD1, si jamais vous avez une idée de ce que je peux creuser, je suis preneur ! Merci pour votre aide

Tout porte à croire que c'est le cluster 028 qui est en cause sur les accès externes.
Seul un expert OVH pourrait le confirmer et y remédier.
Je me permet d'interpeler amicalement @FabienB42 qui est intervenu hier sur ce forum pour un autre sujet !

Oui, après tous les tests effectués, la piste du cluster semble effectivement la plus probable.
Merci pour le contact

Bonjour,

Merci d'avoir pensé à moi, mais je ne saurais vous répondre. Je me renseigne auprès des équipes.

Bonjour,

en effet les appels à google.com n'étaient pas whitelistés depuis les serveurs SSH. Nous venons d'autoriser l'accès sur les ports 80/443, actuellement uniquement sur le cluster028 et demain sur l'ensemble de nos clusters.

Pouvez-vous nous indiquer si c'est ok pour vous maintenant ?

De notre coté :

> myuser@ssh01.cluster028.gra.hosting.ovh.net (php/8.0/production/stable64) ~ $ php -r "echo file_get_contents('https://www.google.com/recaptcha/api/siteverify');"
> {
> "success": false,
> "error-codes": [
> "missing-input-secret"
> ]
> }

Arnaud

@ArnaudF1
Effectivement, ça fonctionne bien pour l'URL https://www.google.com/recaptcha/api/siteverify, mais cette URL n'était qu'un test pour être sûr d'interroger un contenu non restreint.

J'aurais besoin d'accéder à une URL spécifique, et ça ne fonctionne toujours pas.

Faut-il autoriser le domaine concerné ? Je peux vous le communiquer en privé si besoin.

Merci

Oui il faudra autoriser la domaine appelé ainsi que le port de destination.

Vous pouvez me le donner en privé et on verra ce qu'on peut faire. Par contre ce n'est pas sûr que ce soit accepté (et en tout cas pas appliqué aujourd'hui).

Par contre normalement ce genre d'appel est autorisé, via les crons (tâches planifiées) ou via une requête http sur votre site web.

Arnaud

Le problème est réglé, grâce à @ArnaudF1 !

Pour info, les appels à des URL externes ne sont possibles que si le domaine à contacter a été autorisé explicitement sur le cluster concerné.

Merci @ManuelD1 et @Gaston_Phone pour votre aide

Bonjour,

Le problème de file_get_contents bloqué se passe aussi pour toute requête vers un serveur hébergé chez OVH, même dans le même cluster.
Ainsi, dans la console, la requête PHP pour récupérer le contenu d'un fichier local marche:
`php -r "echo file_get_contents('www/thefile.html');"`
Mais la même requête en https sur ce même serveur échoue, ne renvoyant rien, même pas d'erreur !
`php -r "echo file_get_contents('https://XXXXXX.com/thefile.html');"`

@ArnaudF1 Serait-il possible de whitelister les clusters OVH pour la commande file_get_contents ?
La requête HTTPS qui ne marche plus depuis le 29 septembre au soir, provient d'un script PHP sur le cluster010, à destination du cluster007, tous les deux à Gravelines.

Merci.

Bonjour @DamienP26

As-tu essayé avec CURL ?

@Gaston_Phone Merci !! Avec CURL, ça passe.

Maintenant, reste à comprendre quel changement chez OVH a cassé file_get_contents. Ce n'est pas rassurant du tout de se dire qu'il peut y avoir dans le futur un autre tel changement qui casse une autre fonction sans préavis.

@Gaston_Phone Merci !! Avec CURL, ça passe.

Maintenant, reste à comprendre quel changement chez OVH a cassé file_get_contents. Ce n'est pas rassurant du tout de se dire qu'il peut y avoir dans le futur un autre tel changement qui casse une autre fonction sans préavis.

Bonjour @Gaston_Phone

Entre hier et aujourd'hui, j'ai du faire plus de 300 traitements CURL.

Ceci dit, j'utilise la commande
> exec("curl xxxx" , $RESULT);

C'est beaucoup plus rapide à mettre en œuvre et en exécution.

Utilise **WSL Linux bash** pour les tests.