Fanou Posté 6 Mars 2007 Posté 6 Mars 2007 Bonjour à tous. J'ai un petit problème... ou tout du moins me pose une petite question. Afin d'automatiser facilement les liens vers chacuns de mes fichiers, je souhaite indiquer le chemin de mes fichiers php via HTTP. ex : include('http://127.0.0.1/test/include/index.php') ; J'utilise Easyphp 2.0 (beta) et j'obtiens le message d'erreur suivant : URL file-access is disabled in the server configuration Je me suis donc renseigné là-dessus, et cela vient de la configuration PHP ... ( allow_url_fopen ) Je l'ai donc activé, et depuis plus de problème... Mais... Et oui, il y a un mais Cela me fait poser quelques question : Premièrement, c'est bien beau de contourner chacuns de ses soucis en modifiant le fichier php.ini, mais lorsque tout tournera sur un serveur web (sachant que je n'ose pas prendre de serveur dédié vu le peu de connaissance que je possède en la matière) pourrai-je utiliser ce type d'include ? Ce que je veux dire, c'est est-ce que cette option n'est pas activée "uniquement" sur Easyphp ? Ensuite, si cette option n'est pas activée sur des hébergements mutualisés, y a t-il un moyen de contourner cela ? Et enfin, si cette option est activée, est-ce un problème au niveau de la sécurité ? J'espère avoir détaillé comme il faut mon problème. Merci d'avance pour vos réponses. Fanou
Jeanluc Posté 6 Mars 2007 Posté 6 Mars 2007 Bonjour, lorsque tout tournera sur un serveur web (sachant que je n'ose pas prendre de serveur dédié vu le peu de connaissance que je possède en la matière) pourrai-je utiliser ce type d'include ?Cela dépend de l'hébergeur. Le plus simple est de lui poser la question. Ensuite, si cette option n'est pas activée sur des hébergements mutualisés, y a t-il un moyen de contourner cela ?Je ne sais pas, mais cela ne me semble pas être une bonne politique de contourner les règles du jeu fixées par l'hébergeur. Et enfin, si cette option est activée, est-ce un problème au niveau de la sécurité ?Non, tant que tu te limites à un include vers un site de confiance et que tu ne passes pas de paramètre contrôlé par tes visiteurs. Jean-Luc
Fanou Posté 6 Mars 2007 Auteur Posté 6 Mars 2007 Merci Jean-Luc pour ta réponse... Mais je ne comprends pas vraiment ta dernière réponse... Qu'entends-tu par paramètre contrôlé par tes visiteurs ?... Pour infos, mes includes ne sont que ce de mon site... et non pas des fichiers dit externe. Par exemple, je souhaiterai inclure les infos de connections à la BDD... ex : include('http://127.0.0.1/monsite/connect.php'); Cela me permettrai d'indiquer toujours la même variable, et ce quelque soit le dossier dans lequel se trouve ma page php. Cela évite les : include('../../connect.php'); et m'éviterai la mise à jour de mes fichiers si je devais par la suite changer mes dossiers de place... Peux-tu me dire donc si c'est un danger pour la sécurité ?
Jeanluc Posté 6 Mars 2007 Posté 6 Mars 2007 C'est sans danger pour la sécurité, mais je ne vois pas l'intérêt de passer par http pour cet include. Jean-Luc
Fanou Posté 6 Mars 2007 Auteur Posté 6 Mars 2007 (modifié) c'était un exemple... car la pire des choses qui puisse m'arriver serai que l'on puisse récupérer les infos de ma BDD si on l'appelerai d'un autre site. Merci donc pour ta réponse ! Edit : sinon tu me dis que c'est inutile d'appeler mes fichiers de la sorte... aurai-tu un conseil à me donner...? Modifié 6 Mars 2007 par Fanou
Jeanluc Posté 6 Mars 2007 Posté 6 Mars 2007 include('/chemin_absolu/script.php'); me semble aussi pratique que include('http://www.ton_site.com/chemin_web/script.php'); Jean-Luc
Harry_20 Posté 6 Mars 2007 Posté 6 Mars 2007 Je suis d'accord avec Jeanluc ... écrire l'une ou l'autre ligne ne change pas grand chose dans l'histoire. Par ailleurs, tous les hébergeurs n'autorisent pas un include via une url ... car cela peut introduire des problèmes de sécurité. Quoi qu'il en soit, il est préférable de travailler avec des paramètres qui sont les plus standards possible ! Imaginons que dans quelques mois je doive changer d'hébergeur pour une raison X, Y ou Z ... ou que la configuration ne soit modifiée suite à des abus. Dans ce cas, je dois revoir mes fichiers et modifier des infos reprises un peu partout Autrement ... c'est bon !
Fanou Posté 6 Mars 2007 Auteur Posté 6 Mars 2007 Imaginons que dans quelques mois je doive changer d'hébergeur pour une raison X, Y ou Z ... ou que la configuration ne soit modifiée suite à des abus. Dans ce cas, je dois revoir mes fichiers et modifier des infos reprises un peu partout C'est justement pour cette raison que je préférai le faire via URL... car lors de mes développement, j'ai un fichier config sur lequel j'indique mes principales variable... Dans ces variables, l'une d'entre elle est l'url du site lui même... et si je devai changer de nom de domaine, il me suffirai de changer une ligne... Cependant, si mon système venais à évoluer... et il y sera amené... et que je devai ranger différemment mes dossiers, il me faudrai ouvrir chacuns de fichiers php ayant un include de type absolu... Dans tous les cas, je pense que nous avons plus ou moins des façons différentes de développer... Mais pour moi, l'inconnu qui me fait peur, c'est la sécurité... Mais bien entendu, je veux aussi comprendre cela... donc auriez-vous à ce moment là, un lien qui traite des problèmes de sécurité liées à cette methode ? ReMerci
Jeanluc Posté 7 Mars 2007 Posté 7 Mars 2007 Il y a quand même un problème de sécurité avec le passage par http pour l'include. Cela donne accès directement à l'include à partir du web (donc à n'importe qui). Si cela ouvre la porte à des problèmes, il faudrait, par exemple, que tu contrôles l'IP de celui qui appelle l'include et si ce n'est pas l'IP de ton site, tu interromps le traitement. Jean-Luc
Fanou Posté 8 Mars 2007 Auteur Posté 8 Mars 2007 C'est ce que je craignais JeanLuc... donc je vais éviter cette méthode, ou, tout du moins la laisser de côté le temps de maîtriser ce genre de chose. Un grand merci pour votre aide ! Fanou
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant