Discussion :

[schlitters]

Petite question concernant la fonction include() via HTTP, parce que j'ai du mal à comprendre les explications de php.net

Sur le server distant j'ai un fichier php avec des focntions (il n'y a que des fonctions dans ce fichier). Lorsque je fais un include de ce fichier distant dans mon script php local, php me retourne une erreur. Il ne trouve pas la fonction.

Mes deux serveurs sont configurés à l'identique et acceptent l'accès aux fichiers distants soit: allow_url_fopen activé.

Pour testé j'ai écrit un script tout simple sur mon serveur distant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
// serveur distant
<?php
echo 'Hello World';
?>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
//serveur local
<?
include 'http://www.serverdistant.fr';
?>

Là aucun probléme l'affichage hello world se fait trés bien. Donc include() via HTTP fonctionne.

Par contre si je fais:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
// serveur distant
<?php
$a 'Hello World';
?>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
//serveur local
<?
include 'http://www.serverdistant.fr';
echo $a
?>

Là rien s'affiche. Aucune erreur et une page blanche dans mon navigateur.

Si je fais un fonction, j'ai une erreure disant que là fonction est inconnue.

Quelqu'un peut il m'expliquer comment utiliser les fonctions avec un include distant, ou si il me manque quelque chose dans mon code ??

En éspérant avoir été le plus précis possible, d'avance merci

Fred

[Vinzius]

Je dirai le ; qui manque après echo $a !

[ePoX]

Je dirai le ; qui manque après echo $a !

On pourrait dire sa, mais en l'occurence ce n'est pas le problème.

// serveur distant
<?php
$a 'Hello World';
?>

Quand tu appelles cette page, tu déclares la variable $a dans le contexte du serveur distant. donc elle n'est pas communiqué à ton serveur appelant. En PHP deux contextes ne peuvent pas communiquer comme cela.

Ce qu'il faudrait faire c'est que lorsque tu affiches ta page sur le serveur distant le code PHP ne soit pas interprété, mais juste affiché sur la sortie standard (cf navigateur).
De cette manière ton serveur local, inclus la page distante, évalue son contenu, trouve du PHP l'éxecute.
A partir de la tu auras réussi ton execution cross context.

Bon ceci dit c'est bien jolie tout mon zef mais je sais pas trop comment tu vas faire :/

bye

[Herode]

La réponse se trouve ici : http://fr.php.net/manual/fr/function.include.php

En résumé : lorsqu'on fait un include d'un fichier php distant, celui-ci est exécuté sur le serveur (interprété, donc) et son résultat est renvoyé à l'appelant. Comme l'observe ePox, il faut éviter que le fichier soit interprété. Je ne connaissais pas le problème (jamais fait d'include distants), j'ai donc fait un test simplement en donnant une extension .inc à mon fichier distant. Ca marche. Par contre, la doc indique qu'on peut récupérer des valeurs de variables (et exploiter des fonctions) en jouant avec le return quand on conserve l'extension .php . Malheureusement, les explications ne sont pas très claires. Je vous laisse poursuivre l'enquête (mais je suis preneur d'une explication pédagogique une fois le biniou remis d'aplomb 8) )

[schlitters]

Quand tu appelles cette page, tu déclares la variable $a dans le contexte du serveur distant. donc elle n'est pas communiqué à ton serveur appelant. En PHP deux contextes ne peuvent pas communiquer comme cela.

Ce qu'il faudrait faire c'est que lorsque tu affiches ta page sur le serveur distant le code PHP ne soit pas interprété, mais juste affiché sur la sortie standard (cf navigateur).
De cette manière ton serveur local, inclus la page distante, évalue son contenu, trouve du PHP l'éxecute.
A partir de la tu auras réussi ton execution cross context.

Bon ceci dit c'est bien jolie tout mon zef mais je sais pas trop comment tu vas faire :/

bye

ok, je cerne un peu mieux le fonctionnement, par contre il me semblait (en tous cas j'avais cru comprendre) qu'un include ne faisait qu'importer le code dans la page appelante, donc que c'était comme si on écrivait le code du script distant dans la page appelante, et que donc ça n'était pas le serveur distant qui interprété le script distant.

[ePoX]

sa me parait bien bancale ct histoire maurice

[ePoX]

et que donc ça n'était pas le serveur distant qui interprété le script distant.

Et non justement, à partir du moment ou on appelle le fichier php apache demande à php de l'interpreter.
Mais en changeant l'extension sa à l'air de fonctionner. M'enfin je pense que vos mieux eviter ces constructions étranges si il en est.

[schlitters]

La réponse se trouve ici : http://fr.php.net/manual/fr/function.include.php

Je n'ai justement rien trouvé qui pouvait m'aider ....

pour répondre à Vinzius:

Je dirai le ; qui manque après echo $a !

c'était juste une faute de frappe dans mon post !!!

[schlitters]

Et non justement, à partir du moment ou on appelle le fichier php apache demande à php de l'interpreter.
Mais en changeant l'extension sa à l'air de fonctionner. M'enfin je pense que vos mieux eviter ces constructions étranges si il en est.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Un fichier distant peut être traité sur le serveur distant (dépendamment de l'extension du fichier et si le serveur distant exécute PHP ou non) mais il doit toujours produire un script PHP valide parce qu'il sera traité sur le serveur local. Si le fichier du serveur distant doit être traité sur place et affiché seulement, readfile() est une fonction beaucoup plus appropriée. Autrement, vous devriez bien faire attention à sécuriser le script distant afin qu'il produise un code valide et désiré.

Effectivement, en relisant plusieurs fois l'alerte de sécurité ...


Comment puis je faire alors pour inclure un script php distant, dont je ne peux pas changer l'extension (qui restera donc en *.php) mais dont je veux récupérer les fonctions ??

[schlitters]

Ne pouvant pas changer l'extension du script php sur le serveur distant, il ne semble y avoir que deux solutions à mon problème.

• Soit il y a une façon d'empêcher le serveur distant d'interpréter le script php
  
• Soit j'utilise les fonctions de lecture de fichier fopen() fread() etc ... afin de lire le code dans le script distant, et de le retranscrire dans mon script local (j'espère que je suis clair )

Je dois dire que pour l'une ou l'autre de ces deux méthodes je sèche un peu

Si quelqu’un à une idée, ou une autre solution …

[ePoX]

Tu est obligé d'avoir une structure sur deux serveur en même temps ?
Sa me parait un peu étrange.

Mais bon dans la mesure ou tu ne peux rien modifier coté serveur cible, pourquoi ne pas l'attaquer en FTP ?

[schlitters]

Tu est obligé d'avoir une structure sur deux serveur en même temps ?
Sa me parait un peu étrange.

En fait oui et non !!!

Le serveur distant est un serveur web tout ce qu'il y a de plus basique, qui héberge des pages php ne contenant que du texte (dans le sens rédactionnel du terme)

Ce que je nomme le serveur local, est un serveur sur lequel tourne des applis basées sur MySQL (formulaire de recherche, formulaire de saisie etc ...)

Donc pour résumer, un serveur distant "rédactionnel" et un serveur local applicatif.

Dans un soucis d'homogénéité, mes formulaires et autres applications doivent avoir la même charte graphique que la partie rédactionnel ==> cohérence visuel.

Le problème c'est que lorsque le "rédacteur" change les menus d'accès aux pages, ces mêmes menus doivent aussi changer de mon coté.

La communication entre services étant ce qu'elle est, il y a toujours une différence entre les menus du serveur distant et les menu du serveur local. Comme je ne veux pas m'amuser tous les matins à regarder ce qui a changé (en admettant que les mises à jour soit fait le soir et pas n'importe quand dans la journée) et parce que ça n'est pas très dynamique de faire deux fois une chose qui existe, le plus simple et le plus juste (à mon sens) est d'inclure le menu des pages distantes dans mes pages locales.

J'espère que mes explications ont été claires, et j'aurais d'ailleurs peut être dû commencer par là, tout le monde aurait vu où je voulais en venir et aurait pût me diriger vers la meilleurs solution (celle de communiquer avec les autres services LOL )