Bonjour,
Nous avons souscris à un hébergement mutualisé pour héberger notre site de dropshipping. Nous voudrions planifier une tâche CRON qui permet de synchroniser nos stocks avec les données données par le fournisseur.
Cette tâche CRON s’exécuterait plusieurs fois par jour en exécutant un script PHP qui fonctionne globalement comme suit:
1) Téléchargement du fichier CSV des stocks du fournisseur (requête http)
2) Requêtage REST à l'API woocommerce de notre site
2.1) Pour chaque produit enregistré dans notre base de donnée, chercher et mettre à jour par la quantité correspondant dans le csv
Nous nous sommes rendus compte que ce script ne fonctionne pas car il semble après analyse que les connexions sortantes (http entre autres) ne sont pas autorisées sur les serveurs mutualisés.
Ainsi les requêtes effectuées sur le site du type :
- file_get_contents(url_vers_le_csv_à_télécharger.csv)
- curl_exec($curl_vers_l_API_woocommerce)
échouent avec une erreur "connection refused".
Nous voudrions savoir si nous pourrions bénéficier de l'ajout d’exceptions pour les connexions sortantes étant entendu que nous faisons entièrement confiance à notre fournisseur.
D'autre part, nous aimerions savoir s'il y a d'autres moyens d' "obtenir" ce fichier csv. Nous avons pensé à passer par du ftp mais ce fichier n'étant accessible que par un téléchargement via une url http, nous serions obligés d'abord de télécharger ce fichier dans un endroit accessible en ftp, avant de faire un upload, ce que nous ne pouvons pas faire…
Nous ne pouvons pas donner l'intégralité de notre code mais le code responsable du téléchargement du csv est donné ci-dessous :
function downloadCSV()
{
// Use file_get_contents() function to get the file
// from url and use file_put_contents() function to
// save the file by using base name
if (file_put_contents("/XXXXXXX/XXXXXX/www/jobs/data.csv", file_get_contents("https://www.XXXXXX.com/download/stocks_fr_2.csv"))) {
echo "File downloaded successfully";
} else {
echo "File downloading failed.";
}
}
Nous voudrions que cette fonction utilisée dans un script php, puisse télécharger ce fichier csv.
A savoir que le script a été testé en localhost et qu'il fonctionne parfaitement
En vous remerciant
Bonjour @FlorenceM11
As-tu essayé ceci que j'ai utilisé il y a plusieurs années sur les hébergements mutualisés OVH :
https://www.php.net/manual/fr/book.curl.php
> $url = "url_vers_le_csv_à_télécharger.csv";
> $ch_rech = curl_init(); // Initialiser cURL.
> curl_setopt($ch_rech, CURLOPT_URL, $url); // Indiquer quel URL récupérer
> curl_setopt($ch_rech, CURLOPT_HEADER, 0); // Ne pas inclure header dans la réponse.
> ob_start(); // Commencer à 'cache' l'output.
> curl_exec($ch_rech); // Exécuter la requète.
> curl_close($ch_rech); // Fermer cURL.
> $Data_GET = ob_get_contents(); // Sauvegarder 'cache' dans variable $Data_GET
> ob_end_clean(); // Vider le buffer.
Bonjour @Gaston_Phone ,
Merci pour ta réponse, nous avons repris ton code pour avoir le code ci-dessous :
#!/usr/local/php8.0/bin/php
function downloadCSV() {
$url = "https://www.XXXXXXXXX/stocks_fr_2.csv";
$ch_rech = curl_init(); // Initialiser cURL.
curl_setopt($ch_rech, CURLOPT_URL, $url); // Indiquer quel URL récupérer
curl_setopt($ch_rech, CURLOPT_HEADER, 0); // Ne pas inclure header dans la réponse.
ob_start(); // Commencer à 'cache' l'output.
curl_exec($ch_rech); // Exécuter la requète.
curl_close($ch_rech); // Fermer cURL.
$Data_GET = ob_get_contents(); // Sauvegarder 'cache' dans variable $Data_GET
echo "$Data_GET";
file_put_contents("/homez.1013/skhncbe/www/jobs/data.csv", $Data_GET);
ob_end_clean(); // Vider le buffer.
}
downloadCSV();
?>
Malheuresement, nous avons vu que l'éxécution plante au niveau du ob_start(). Donc nous avons essayé de prendre directement la réponse sans passer par le cache.
#!/usr/local/php8.0/bin/php
function downloadCSV()
{
$url = "https://www.XXXXXXXXX/download/stocks_fr_2.csv";
$ch_rech = curl_init(); // Initialiser cURL.
curl_setopt($ch_rech, CURLOPT_URL, $url); // Indiquer quel URL récupérer
curl_setopt($ch_rech, CURLOPT_HEADER, 0); // Ne pas inclure header dans la réponse.
// ob_start(); // Commencer à 'cache' l'output.
$response = curl_exec($ch_rech); // Exécuter la requète.
curl_close($ch_rech); // Fermer cURL.
if (!$response) {
echo "KO";
} else {
$Data_GET = $response; // ob_get_contents(); // Sauvegarder 'cache' dans variable $Data_GET
file_put_contents("/homez.1013/skhncbe/www/jobs/data.csv", $Data_GET);
ob_end_clean(); // Vider le buffer.
}
}
downloadCSV();
?>
Et là aussi nous avons constaté un "KO", ce qui signifie que la response est false…
Donc pour le moment, on a toujours le même problème…
D'autre part, étant connecté en ssh, je lance la commande suivante :
wget https://www.XXXXXXXXXXX/download/stocks_fr_2.csv
Et j'obtiens le résultat suivant :
--2021-02-06 10:09:55-- https://www.XXXXXXXXXXX/download/stocks_fr_2.csv
Résolution de www.XXXXXXXXXXX (www.XXXXXXXXXXX)… 163.172.101.138
Connexion à www.XXXXXXXXXXX (www.XXXXXXXXXXX)|163.172.101.138|:443… échec : Connexion refusée.
163.172.101.138
Il n'est pas exclu que ce soit le serveur 163.172.101.138, celui du fournisseur, qui bloque la connexion depuis votre site. Pour vérifier cela, avez vous essayé de faire un wget vers d'autres adresses quelconques sur web ? Si le wget fonctionne alors sans problème, il y a de fortes chances pour que ce soit effectivement 163.172.101.138 qui bloque votre site (ou bien l'adresse IP de votre site).
Merci pour la réponse @Nico94,<br /><br />Je viens de tester sur des sites http et https sans succès, j'obtient les résultats suivants:<br /><br />Image du plan du site du chateau de versaille (http)<br /><br /> Connexion à www.chateauversailles.fr (www.chateauversailles.fr)|178.237.109.77|:80… échec : Connexion refusée.<br /><br />Fichier texte sur w3.org (https)<br /><br /> Connexion à www.w3.org (www.w3.org)|128.30.52.100|:443… échec : Connexion refusée.<br /><br />Donc cela se pourrait-il que l'IP du serveur soit blacklisté sur la plupart des sites... ? Je trouve ça étrange...
Bonjour,
n'essayez pas de faire le test en SSH les connexion sortante sont bridés.
Cordialement, janus57
@janus57,
D'accord, est-ce que je dois donc comprendre que le script que j'ai décrit 3 posts avant devrait fonctionner en le planifiant dans une tâche CRON ?
Comment peut-on tester le script, étant donnée que j'ai déjà lancé le script php depuis le site en faisant
http://mypersonaldomain.ovh/jobs/test.php
et que tout fonctionnait parfaitement,
En vous remerciant,
Bonjour,
aucune idée pour les tâches cron j'ai pas de vrais mutu chez OVH.
Mais si le script fonctionne en l'appelant via un navigateur perso je contournerai le problème en appelant le script depuis l'extérieur directement sur votre site via un système de webcron (ou un monitoring externe par exemple).
Cordialement, janus57
Effectivement cela pourrait être une solution, donc nous pourrions utiliser un service de monitoring externe(webcron). Si quelqu'un a déjà été face cette problématique, pourriez-vous nous conseiller sur la marche à suivre pour cela…
Sinon, nous aimerions vraiment pouvoir executer notre script en interne sans passer par un service externe…
Je n'ai pas non plus de mutu OVH pour tester exhaustivement, mais il est tout à fait possible que le script puisse fonctionner en passant par le web (http://mypersonaldomain.ovh/jobs/test.php) et pas en cron. Les modes d'exécution de PHP ne sont pas forcément les mêmes dans les 2 cas et les bridages non plus. Si cette hypothèse se vérifie, vous n'avez effectivement d'autre choix que de (1) passer sur un autre hébergement ou (2) passer sur un service du genre webcron.
Je vous remercie pour vos réponses, je pense que nous allons partir sur l'option du service webcron, cependant notre script peut mettre plusieurs heures à s'éxécuter… Connaissez-vous un service webcron qui permette d'avoir un timeout assez grand pour laisser au script le temps de mettre à jour la base de données ?
Bonjour,
cependant notre script peut mettre plusieurs heures à s'éxécuter
dans ce cas vous pouvez tout de suite oublier le fait de le faire tourner sur un mutu OVH qui va obligatoirement couper votre script au bout de +/-160secondes.
Un script qui met plusieurs heures sur un mutu c'est impensable/impossible.
Cordialement, janus57
Bien, je crois qu'après ces explications, tout est plus clair, il semble évident qu'un hébergement mutu n'est pas adapté pour un site commercial. Nous allons opter pour un ordinateur qui tournera en permanence pour mettre à jour nos données.
Dommage qu'il n'y ait pas eu plus d'avertissement plus clair concernant nos droits avant de nous lancer sur ce type d’hébergement.