Important à Lire, Faille critique PHP

bah ca m'intéresse parceque oui, ils sont sur le meme hébergement, en fait sur le meme site. zobi étant dans un sous rep du dossier contenant pouet.

sinon l'astuce du localhost j'ai essayé mais rien à faire.

question bête qui a sûrement une justification alors, pourquoi ne pas utiliser require() ou include() ?

S'il y a une bonne raison, tu peux ruser pour récupérer la sortie avec la Bufferisation de sortie : ob_start(), ob_end_flush(), ob_get_contents()

bah...
j'ai besoin de passer des paramètres à l'exécution du script donc
include() : on m'a dit plus haut que ca n'avait pas de sens, donc j'ai même pas tenté le coup.
require() : j'connais pas, vais essayer.

quant au reste je le creuse.

merci pour toutes ces réponses

bon ca y'est, je tiens la soluce.
require() avait le meme probleme avec les params que include().
mais de fil en aiguille je suis tombé sur eval()
qui écxécute une chaine contenant un code php.
donc je lis le contenu de feu zobi.php qui devient zobi.script, qq str_replace pour mettre à jour dans le code les paramètres attendus par la valeur que je voulais passer....
et ma foi c'est bon.
c'est cool en plus ca limite grandement la portée des scripts ainsi exécutés (plus d'includes entrautre)

voilà sur ce bonne nuit !

euhhh et créer une fonction, c'est pas plus simple ? j'ai pas bien compris le probleme... pour appeler du code PHP en passant des paramètres, c'est ce qui me semble correspondre

Oui, moi non plus sur ce coup là j'ai pas tout compris...

vous me rassurez

Pour les débutant ou pour ceux qui n'avait pas compris comment palier a la faille :

explication

Nan, ce qu'on a pas compris c'est le problème de zumba qui veut faire des include avec paramètres... Autant faire une fonction non, c'est le but ?

euh alors pour ceux qui n'ont pas compris (si ca concerne ce que je dis), le but est de permettre d'encastrer des modules de code de manière générique (sorts, évènements roleplay divers et variés...) développés par des tiers, et s'interfacant avec le moteur du jeu.
mais je ne sais pas à priori quel sera l'effet (donc le code) ni les paramètres de ces fonctions.

Autre avantage de considerer le script pluggable comme un fichier texte à la con est que je peux facilement distinguer la partie code et une partie déclaration (nom, descriptif, params,....) que je peux réutiliser pour generer une ihm de paramétrage des scripts

bon honnêtement au début j'étais parti là dessus car ces modules auraient pu être stockés sur d'autres sites mas c'est vrai que si je les force sur le même site, je pourrais faire un include et forcer un nom de fonction générique avec tous les paramètres crunchés dans une chaîne, vous avez raison.
Problème, on en revient à un include dynamique et a la toute première problématique de ce thread, ne connaissant pas le nombre ni les noms des scripts pluggables je ne peux pas switcher dessus, je dois forcément faire un include ($nom_script)...

Pas très propre tout ça, quand même.

Ca reste pas très propre mais c'est déjà moins crade que des eval() et compagnie.

Au fait pour ceux qui ne savaient pas, on peux utiliser les return dans des fichier inclus.

ouarf desolé j'aurais du expliquer pourquoi cela n'avait pas de sens...

bon alors cela n'a pas de sens car:

include("toto.php?a=1");
voudrait dire que tu charge tto avec a =1

hors il suffit de faire

$a=1;
include ("toto.php");

pour executer le toto avec a=1

le include est un "copié collé"

il a le même resultat que si tu avais tout mis dans le même fichier mais permets de ranger un peu ses scripts et de s'organiser dans son code.

desolé, je ne penses pas que tu ai besoin de l'armée des modules...

@gorgu :
eh bien oui mais le problème est que je ne sais pas a priori quels sont les paramètres à fournir. ca peut etre a tout seul comme b et c grouppés ou autre...
pour poser le cas général : ce n'est pas moi qui vais développer ces scripts, n'importe qui pourra le faire mais en s'appuyant sur une seule include que je contrôle (avec tous les tests anti gruge).

@nono:
pas mal, cimer. Je vais essayer mais j'ai un doute là aussi sur le passage des params que je ne connais pas. Mais en gros il faut juste que je crée le tableau dynamiquement a partir du crunch des params (que j'ai en base)
Sinon Le seul truc qui me fait encore hésiter avec le eval est la récupération du descripteur du module, pour l'IHM ou génère un déclenchement diu script (décrivant ce qu'il fait, les params dont il a besoin, les defaults...)

@+

Ben si tu as l'url, je suppose que tu as les params, non ?

Dans le pire des cas tu parse l'url :

C'est encore plus crade, mais toujours moins que le eval et les str_replace sur le fichier.

Encore mieux (pquoi réinventer la roue ?) : parse_str

Si on veut faire moins crade et éviter l'écrasement de variable, on reprend la fonction includeModule :

eh bien oui c'était pourtant con.
mais qu'est ce que je suis allé me faire chier avec les fopen et les appels distants...
déformation professionelle sûrement...

merci nono & tlm

ouarf...

tu désires rapartier un script et le faire tourner chez toi comme cela???

par ouverture de lien externe?

Sinon y'avait le xmlrpc voire un petit coup de corba

Salut à tous,
Je me permet de revenir au problème initial pour solliciter une aide de votre part

J'ai commencé à coder un site en Php il y a quelques temps et j'ai pondu un truc comme ça (pour chaque page)

include(include/ctrl_ident.php)
include(include/fonctions.php)
include (include/haut_de_page.php)
>> description de la page <<
include(include/bas_de_page)

avec :
ctrl_ident pour faire les ctrls liés à la connexion
haut_de_page et bas_de_page pour le menu et la structure du site, ce qui me permet de me concentrer sur la page en elle meme
Ce code a été fait avec la version 3 de php et marche assez bien

J'en viens à mon (mes?) problème :

Plutot que de faire ce que j'ai decrit je voulais remanier le code pour que l'utilisateur n'attaque que la page index.php, ce qui donne quelque chose comme ça (la syntaxe est peut etre fausse mais ce n'est pas le probleme) pour la page index.php :

include(include/ctrl_ident.php)
include(include/fonctions.php)
include (include/haut_de_page.php)

include('../include/pages/ ' . $SESSION[page])

include(include/bas_de_page)

Mes questions :
- Est-ce que le fait de faire un include d'une page passée par la session, avec en plus un chemin spécifique protége du problème que vous decrivez ?
- serait-il pour une autre raison plus pratique d'en passer par des switch dans la page index ?

Et deux autres qui m'aideraient bien :
- est-ce qu'il est préférable/pratique d'utiliser des templates (dont je decouvre a peine l'utilisation) pour gerer la structure du site, plutot que de procéder par include d'un haut de page ?
- le fait que le ctrl_ident (qui gere l'authentification de l'utilisateur) soit sur la page index permet-il d'afficher ,sans controle, la page tructruc.php si on l'appel directement ?Il faudrait peut-etre mieux faire l'include du ctrl_ident sur chaque page ? ou y a t-il une autre méthode ?

Merci pour vos réponses

A+
Dem666

a prioris, ta methode est une faille possible car tout dépends de comment tu definit la variable de session page

pour les templates, ... depends uniquement de toi .

j'utilises la même methode que toi.

c'est ensuites dans page justement que tu pourrais utiliser des templates.

Il faut tout de même bien choisir son moteur de templates car ils sont parfois lourd.
l'utilisation de css et xhtml remplace cela avantageusement je trouve...

Merci pour tes réponses mais ...
Une variable de session peut-etre modifiée par un utilisateur mal intentionné ?

Qu'en est-il pour mon controle de l'identité ?

tu dois avoir un session_register("page);

mais avant "un truc" qui definit $page.

c'est ce truc qui peu poser soucis