fopen( script.php, rt) => acces refuse
Patrick 'Zener' Brunet
Navr� du bas niveau de la question, mais je n'ai pas trouv� avec Google:
Dans le cadre d'un serveur de contenu un peu complexe, j'ai un script qui va
inclure (@include) un certain nombre d'autres, qui sont donc des PHP,
mais auparavant il doit rassembler dans une structure des donn�es qui sont
r�parties dans ces m�mes scripts.
Et donc dans un but d'optimisation et aussi de simplicit� de programmation,
je voudrais que le ma�tre-script commence par les ouvrir comme des fichiers
pour en lire uniquement un header de 2 lignes (implant� comme un commentaire
au d�but de chaque script).
Cette ouverture par fopen("rt") �choue: le fichier n'existe pas.
J'ai v�rifi� que le path est bon et �a marche bien si l'extension n'est pas
.php, donc j'en d�duis que c'est le serveur qui est configur� pour que les
PHP ne soient accessibles qu'en ex�cution ?
A priori je ne ma�trise pas cet aspect de la config:
- il n'y a pas de .htaccess qui soit en rapport,
- je constate le probl�me sur le serveur de Test qui est EasyPHP,
- le serveur de production est un h�bergement mutualis� (OVH).
Si une telle protection est en place pour les PHP, je ne vois pas comment la
contourner depuis un script (faire des chmod ???).
* Une confirmation d'expert pour le sc�nario ?
* Une id�e de solution ?
La mienne est bien s�r d'�clater chaque script pour en extraire un fichier
descripteur qui soit lisible, mais �a signifie g�rer des paires au lieu de
fichiers uniques, ce qui n'est jamais bon pour la fiabilit�.
Merci.
--
Cordialement.
* Patrick BRUNET www.ipzb.fr www.ipzb-pro.com
* E-mail: lien sur http://zener131.eu/ContactMe
Olivier Miakinen
>
> Dans le cadre d'un serveur de contenu un peu complexe, j'ai un script qui va
> inclure (@include) un certain nombre d'autres, qui sont donc des PHP,
> rï¿œparties dans ces mï¿œmes scripts.
>
> Et donc dans un but d'optimisation et aussi de simplicitￜ de programmation,
> je voudrais que le maï¿œtre-script commence par les ouvrir comme des fichiers
> pour en lire uniquement un header de 2 lignes (implantￜ comme un commentaire
> au dï¿œbut de chaque script).
Ok.
> Cette ouverture par fopen("rt") ï¿œchoue: le fichier n'existe pas.
>
> J'ai vￜrifiￜ que le path est bon et ￜa marche bien si l'extension n'est pas
> .php, donc j'en dￜduis que c'est le serveur qui est configurￜ pour que les
> PHP ne soient accessibles qu'en exï¿œcution ?
Alors ￜa, j'ai vraiment du mal ￜ le croire. Un fichier que tu n'arrives
pas ￜ ouvrir, tu le renommes pour changer l'extension, ￜa marche, puis
tu le renommes pour remettre .php et ï¿œa ne marche plus ??? Avec comme
message d'erreur que le fichier *n'existe pas* ?????
Vï¿œrifie, ï¿œa me semble vraiment trop ï¿œnorme. Tu vois ï¿œa sous quel systï¿œme
d'exploitation ?
> A priori je ne maï¿œtrise pas cet aspect de la config:
> - il n'y a pas de .htaccess qui soit en rapport,
Attends voir... tu accï¿œdes bien au fichier en direct, via le systï¿œme de
fichiers, et pas via une url, n'est-ce pas ? Parce que si c'est via une
url (et que le serveur http a donc quelque chose ￜ y voir, fichier
.htaccess et le toutime), il est tout ￜ fait normal que tu ne puisses
pas lire son code source sans interprï¿œtation.
> --
> Cordialement.
Tiens, ton dï¿œlimiteur de signature est incorrect. Mais je crois qu'avec
la vieille version d'OE que tu utilises ï¿œa ne peut se corriger qu'avec
OE-Quotefix.
Cordialement,
--
Olivier Miakinen
Patrick 'Zener' Brunet
Je rￜpond ￜ ￜa sￜparￜment parce que ￜa risque de dￜclencher un tollￜ. Et
pourtant...
"Olivier Miakinen" <om+...@miakinen.net> a ï¿œcrit dans le message
de news 4ac8aabf$1...@meta.neottia.net
> Le 04/10/2009 15:12, Patrick 'Zener' Brunet a ï¿œcrit :
>> [...]
>> Cordialement.
>
> Tiens, ton dï¿œlimiteur de signature est incorrect. Mais je crois
> qu'avec la vieille version d'OE que tu utilises ï¿œa ne peut se
> corriger qu'avec OE-Quotefix.
>
> Cordialement,
J'ai OE-Quotefix, mais il me fait des saletￜs en s'attaquant aussi ￜ des
emails en HTML...
J'espￜre que je l'ai mieux rￜglￜ cette fois.
J'ai aussi fait l'effort de migrer vers ThunderBird, mais j'ai fini par
revenir sur OE parce que je trouvais TB ingï¿œrable sur deux points
essentiels:
- infoutu de me prï¿œsenter les messages de news comme OE: groupï¿œs par
conversations + les plus rï¿œcents en haut + les suivis au sommet,
- gestion et insertion des signatures HTML absolument inepte, mï¿œme avec les
plugins que j'ai pu trouver.
Je sais que c'est pas bien le HTML, mais pour faire des emails pros qui
ressemblent ￜ quelque chose (mￜme si le code lui-mￜme est assez pourri),
c'est incontournable. De toute maniï¿œre, quand la rï¿œponse est passï¿œe par
Lotus ou un autre truc dans le genre, c'est pas triste...
Bon, OE est capable de planter de temps en temps en insï¿œrant la signature,
mais on vit avec, Notepad est mon ami pour sauver le texte...
Celui-ci est la v.6 de Win2000pro + quelques mises ￜ jour... Bientￜt je vais
migrer sur celui de XP, je finis de configurer la nouvelle station de comm
:o)
En attendant de trouver un truc qui marche comme JE veux, ou d'en ï¿œcrire un
;-)
Patrick 'Zener' Brunet
"Olivier Miakinen" <om+...@miakinen.net> a ï¿œcrit dans le message
de news 4ac8aabf$1...@meta.neottia.net
> Le 04/10/2009 15:12, Patrick 'Zener' Brunet a ï¿œcrit :
>>
>> Dans le cadre d'un serveur de contenu un peu complexe, j'ai un
>> script qui va inclure (@include) un certain nombre d'autres, qui
>> sont donc des PHP,
>> mais auparavant il doit rassembler dans une structure des donnï¿œes
>> qui sont rï¿œparties dans ces mï¿œmes scripts.
>>
>> Et donc dans un but d'optimisation et aussi de simplicitￜ de
>> programmation, je voudrais que le maï¿œtre-script commence par les
>> ouvrir comme des fichiers pour en lire uniquement un header de 2
>> lignes (implantￜ comme un commentaire au dￜbut de chaque script).
>
> Ok.
>
>> Cette ouverture par fopen("rt") ï¿œchoue: le fichier n'existe pas.
>>
>> J'ai vￜrifiￜ que le path est bon et ￜa marche bien si l'extension
>> n'est pas .php, donc j'en dï¿œduis que c'est le serveur qui est
>> configurￜ pour que les PHP ne soient accessibles qu'en exￜcution ?
>
> Alors ￜa, j'ai vraiment du mal ￜ le croire. Un fichier que tu
> n'arrives pas ￜ ouvrir, tu le renommes pour changer l'extension, ￜa
> marche, puis tu le renommes pour remettre .php et ï¿œa ne marche plus
> ??? Avec comme message d'erreur que le fichier *n'existe pas* ?????
>
> Vï¿œrifie, ï¿œa me semble vraiment trop ï¿œnorme. Tu vois ï¿œa sous quel
> systï¿œme d'exploitation ?
>
Oh que oui j'ai vￜrifiￜ ! J'ai changￜ le maￜtre script pour qu'il cherche
des ".test" et renommￜ les fichiers en consￜquence, et lￜ ￜa marche.
Mais ï¿œvidemment plus question de les "includer" avec exï¿œcution du PHP
ensuite, a priori.
Sauf peut-ￜtre en dￜclarant cette extension comme alias de ".php", mais ￜ
mon avis ï¿œa rï¿œveillera le problï¿œme initial.
J'ai dￜjￜ constatￜ ce comportement sous Linux, avec le droit "r" manquant
pour le rï¿œpertoire, il me semble...
La commande ls ne voit rien malgrￜ le passage d'un nom explicite.
Par ailleurs, le message d'erreur est ce que le PHP renvoie dans le code
produit. Je doute qu'ils aient prï¿œvu ï¿œa, alors ï¿œa doit se rabattre sur une
cause probable. Mais lￜ c'est faux, le fichier existe et sans erreur dans
son nom.
Pour l'instant je teste en local sous Windows, mais j'ignore comment c'est
codￜ dans EasyPHP. Ca ne me paraￜt pas incohￜrent.
Mais de toute maniï¿œre je ne pourrai pas faire reposer l'architecture sur
cette solution s'il y a un tel alï¿œa selon l'implï¿œmentation de PHP utilisï¿œe.
Tu y arrives ￜ ouvrir des PHP avec un fopen toi ?
>> A priori je ne maï¿œtrise pas cet aspect de la config:
>> - il n'y a pas de .htaccess qui soit en rapport,
>
> Attends voir... tu accï¿œdes bien au fichier en direct, via le
> systï¿œme de fichiers, et pas via une url, n'est-ce pas ? Parce que
> si c'est via une url (et que le serveur http a donc quelque chose ￜ
> y voir, fichier .htaccess et le toutime), il est tout ￜ fait normal
> que tu ne puisses pas lire son code source sans interprï¿œtation.
>
Non, c'est bien par son path relatif et en mode fichier, pas en mode http.
En fait il n'y a pas de protocole, juste un nom de fichier, et c'est bien
l'extension qui fait que ï¿œa marche ou pas.
Merci pour ta participation.
Olivier Miakinen
>
> Oh que oui j'ai vￜrifiￜ ! J'ai changￜ le maￜtre script pour qu'il cherche
> des ".test" et renommￜ les fichiers en consￜquence, et lￜ ￜa marche.
C'est vraiment bizarre. Et il est dￜjￜ incomprￜhensible que PHP puisse
lire un fichier par include() mais pas l'ouvrir par fopen("rt") : en
principe ce sont les mï¿œmes droits qui sont demandï¿œs, et par le mï¿œme
utilisateur !
> Mais ï¿œvidemment plus question de les "includer" avec exï¿œcution du PHP
> ensuite, a priori.
Hein ? Et pourquoi donc ? Tu as essayￜ aussi et ￜa ne marche pas ???
En principe on ï¿œvite de mettre une extension autre que .php pour ï¿œviter
qu'ils soient lisibles directement de l'extï¿œrieur, mais le mieux est de
les mettres dans un coin de l'arborescence inaccessible ￜ Apache, et
dans ce cas tu peux bien les suffixer comme tu veux.
> Sauf peut-ￜtre en dￜclarant cette extension comme alias de ".php", mais ￜ
> mon avis ï¿œa rï¿œveillera le problï¿œme initial.
Mais bon sang, un include() ne repasse pas plus par le serveur http
qu'un fread() !
> J'ai dￜjￜ constatￜ ce comportement sous Linux, avec le droit "r" manquant
> pour le rï¿œpertoire, il me semble...
> La commande ls ne voit rien malgrￜ le passage d'un nom explicite.
Il est exact que les droits sur le rï¿œpertoire peuvent autoriser ou
interdire l'accï¿œs au fichier, mais je ne comprends pas comment ï¿œa
pourrait agir diffï¿œremment sur un include() ou sur un fopen() en
mode "r".
> Par ailleurs, le message d'erreur est ce que le PHP renvoie dans le code
> produit. Je doute qu'ils aient prï¿œvu ï¿œa, alors ï¿œa doit se rabattre sur une
> cause probable. Mais lￜ c'est faux, le fichier existe et sans erreur dans
> son nom.
>
> Pour l'instant je teste en local sous Windows, mais j'ignore comment c'est
> codￜ dans EasyPHP. Ca ne me paraￜt pas incohￜrent.
Moi ￜa me paraￜt complￜtement incohￜrent car j'ai toujours pensￜ que la
fonction fopen(), avec un nom de fichier, se contentait d'appeler le
fopen() de la libc, celui qui existait dￜjￜ depuis de nombreuses annￜes
avant l'invention de PHP.
> Tu y arrives ￜ ouvrir des PHP avec un fopen toi ?
Je n'ai pas essayￜ avec fopen(), mais avec readfile() je le fais trￜs
couramment, sans aucun problￜme. Tu peux dￜjￜ essayer ￜa.
> Non, c'est bien par son path relatif et en mode fichier, pas en mode http.
Ok. Et l'include() aussi, bien sï¿œr ? Et si tu esayais avec un chemin
absolu pour les deux ? Le problï¿œme ne serait-il pas qu'il trouve le
fichier include() grￜce ￜ l'include_path ? Mais je ne comprends pas
comment un simple changement de nom modifierait le comportement. Cela
ï¿œtant dit, un paramï¿œtre du fopen() te permet d'utiliser l'include_path.
Par ailleurs :
<cit. http://fr.php.net/manual/fr/function.fopen.php>.
[...] droits d'accￜs ￜ ce fichier. Si vous activez le safe mode, ou la
directive open_basedir, d'autres conditions peuvent aussi s'appliquer.
</cit.>
> En fait il n'y a pas de protocole, juste un nom de fichier, et c'est bien
> l'extension qui fait que ï¿œa marche ou pas.
C'est vraiment ï¿œa le plus curieux. Que ce soit pour include() ou pour
fopen(), un fichier reste un fichier, qu'il s'appelle truc.php, truc.txt
ou encore php.jpeg.ini.brunet.miakinen !
Encore une autre idï¿œe : puisque tu es sur Windows, ce ne serait pas un
problï¿œme entre le nom court (8+3) et le nom long, ou bien avec un
mï¿œlange de casses ? Je dis problablement n'importe quoi, mais rien qui
ne me semble plus incroyable que le fait d'un comportement qui change
quand tu renommes machin.php en machin.test.
--
Olivier Miakinen
Olivier Miakinen
Le 06/10/2009 00:40, Patrick 'Zener' Brunet a ï¿œcrit :
>
> Je rￜpond ￜ ￜa sￜparￜment parce que ￜa risque de dￜclencher un tollￜ.
Oui, tu as raison, d'ailleurs je fais suivre vers le groupe idoine.
>> Tiens, ton dï¿œlimiteur de signature est incorrect. Mais je crois
>> qu'avec la vieille version d'OE que tu utilises ï¿œa ne peut se
>> corriger qu'avec OE-Quotefix.
>
> J'ai OE-Quotefix, mais il me fait des saletￜs en s'attaquant aussi ￜ des
> emails en HTML...
Comme je n'ai jamais utilisￜ OE, je ne connais pas Quotefix non plus,
et donc je ne peux pas te conseiller. L'idï¿œal serait probablement, si
c'ï¿œtait possible, qu'il traite diffï¿œremment le courriel et les news
(lesquels, du moins sur fr.*, sont toujours en texte brut).
> J'espￜre que je l'ai mieux rￜglￜ cette fois.
Non, ￜa n'a pas marchￜ, mais bon, ce n'est pas si grave que ￜa : je ne
te le signalais qu'ￜ l'occasion de ma rￜponse sur ton problￜme PHP.
> [...]
> Celui-ci est la v.6 de Win2000pro + quelques mises ￜ jour... Bientￜt je vais
> migrer sur celui de XP, je finis de configurer la nouvelle station de comm
> :o)
Raison de plus pour ne pas t'embï¿œter avec ta signature sur ton vieil OE.
Quand tu auras la derniï¿œre version d'XP, OE ne te bouffera plus l'espace
aprï¿œs les deux traits.
Cordialement,
--
Olivier Miakinen
Patrick 'Zener' Brunet
"Olivier Miakinen" <om+...@miakinen.net> a ï¿œcrit dans le message
de news 4acaf3dd$1...@meta.neottia.net
> Le 06/10/2009 00:40, Patrick 'Zener' Brunet a ï¿œcrit :
>>
>> Oh que oui j'ai vￜrifiￜ ! J'ai changￜ le maￜtre script pour qu'il
>> cherche des ".test" et renommￜ les fichiers en consￜquence, et lￜ
>> ï¿œa marche.
>
> C'est vraiment bizarre. Et il est dￜjￜ incomprￜhensible que PHP
> puisse lire un fichier par include() mais pas l'ouvrir par
> fopen("rt") : en principe ce sont les mï¿œmes droits qui sont
> demandï¿œs, et par le mï¿œme utilisateur !
>
Il me semble que ￜa pourrait ￜtre une sￜcuritￜ ￜvitant d'accￜder en lecture
ￜ des scripts... Foireux mais plausible.
C'est pouquoi je disais:
>> Mais ï¿œvidemment plus question de les "includer" avec exï¿œcution
>> du PHP ensuite, a priori.
>
> Hein ? Et pourquoi donc ? Tu as essayￜ aussi et ￜa ne marche pas ???
> En principe on ï¿œvite de mettre une extension autre que .php pour
> ï¿œviter qu'ils soient lisibles directement de l'extï¿œrieur, mais le
> mieux est de les mettres dans un coin de l'arborescence
> inaccessible ￜ Apache, et dans ce cas tu peux bien les suffixer
> comme tu veux.
C'est vrai, ￜa ne n'ai pas encore essayￜ. Il n'y a pas de risque parce que
j'ai un "deny from all" sur toute l'arborescence.
Mais lￜ encore, je ne connais pas assez bien l'ￜme d'Apache pour ￜtre sￜr
que toute version exï¿œcute un fichier inclus depuis du PHP mï¿œme si
l'extension n'est pas dï¿œclarï¿œe comme telle...
>> Sauf peut-ï¿œtre en dï¿œclarant cette extension comme alias de ".php",
>> mais ￜ mon avis ￜa rￜveillera le problￜme initial.
>
> Mais bon sang, un include() ne repasse pas plus par le serveur http
> qu'un fread() !
>
Non, il n'y a pas de requￜte HTTP ￜ ce niveau, seulement la requￜte
d'origine pour la page, ensuite on est bien dans l'inclusion en mode fichier
partout.
>> [...]
>> Tu y arrives ￜ ouvrir des PHP avec un fopen toi ?
>
> Je n'ai pas essayￜ avec fopen(), mais avec readfile() je le fais
> trￜs couramment, sans aucun problￜme. Tu peux dￜjￜ essayer ￜa.
>
readfile() ne m'arrange pas parce qu'il dï¿œvore le fichier entier, alors que
mon but est de ne lire que le header de 2 lignes.
Mais ce que tu dis confirmerait que c'est mon EasyPHP qui fait des
maniï¿œres...
>> Non, c'est bien par son path relatif et en mode fichier, pas en
>> mode http.
>
> Ok. Et l'include() aussi, bien sï¿œr ? Et si tu esayais avec un chemin
> absolu pour les deux ? Le problï¿œme ne serait-il pas qu'il trouve le
> fichier include() grￜce ￜ l'include_path ? Mais je ne comprends pas
> comment un simple changement de nom modifierait le comportement.
> Cela ï¿œtant dit, un paramï¿œtre du fopen() te permet d'utiliser
> l'include_path.
>
> Par ailleurs :
> <cit. http://fr.php.net/manual/fr/function.fopen.php>.
> [...] droits d'accￜs ￜ ce fichier. Si vous activez le safe mode, ou
> la directive open_basedir, d'autres conditions peuvent aussi
> s'appliquer. </cit.>
>
open_basedir aurait pu... En effet j'essaie aussi de mutualiser un moteur
entre plusieurs sites, et donc je suis amener ￜ utiliser des chemins en
../Engine et ../SiteN
Mais ï¿œa ne changerait pas de comportement avec l'extension.
>> En fait il n'y a pas de protocole, juste un nom de fichier, et
>> c'est bien l'extension qui fait que ï¿œa marche ou pas.
>
> C'est vraiment ï¿œa le plus curieux. Que ce soit pour include() ou
> pour fopen(), un fichier reste un fichier, qu'il s'appelle
> truc.php, truc.txt ou encore php.jpeg.ini.brunet.miakinen !
>
C'est vrai que j'utilise des sous-extensions en gï¿œnï¿œral et donc aussi dans
mes scripts: genre
Item.script.php pour distinguer de
Contenu.page.php par exemple.
Mï¿œme Windows s'en fiche et ne considï¿œre que l'extension finale.
Mais s'il y a un problï¿œme de codage dans EasyPHP, sait-on jamais...
C'est vrai qu'en changeant *toute l'extension* en ".txt" j'ai fait
disparaï¿œtre le point intermï¿œdiaire.
Je retesterai cette hypothï¿œse
> Encore une autre idï¿œe : puisque tu es sur Windows, ce ne serait pas
> un problï¿œme entre le nom court (8+3) et le nom long, ou bien avec un
> mï¿œlange de casses ? Je dis problablement n'importe quoi, mais rien
> qui ne me semble plus incroyable que le fait d'un comportement qui
> change quand tu renommes machin.php en machin.test.
J'utilise des noms longs et du mix de casse en effet, mais c'est vrai aussi
avec l'extension qui marche.
Bon, tu me rassures lￜ, si c'est normalement possible, je dois avoir un
problï¿œme avec mes outils de test. Je vais creuser ï¿œa...
Merci.
Olivier Miakinen
>>
>> C'est vraiment bizarre. Et il est dￜjￜ incomprￜhensible que PHP
>> puisse lire un fichier par include() mais pas l'ouvrir par
>> fopen("rt") : en principe ce sont les mï¿œmes droits qui sont
>> demandï¿œs, et par le mï¿œme utilisateur !
>
> Il me semble que ￜa pourrait ￜtre une sￜcuritￜ ￜvitant d'accￜder en lecture
> ￜ des scripts... Foireux mais plausible.
Qu'il y ait une sￜcuritￜ pour ￜvider d'accￜder en lecture ￜ certaines
parties de l'arborescence, ￜa me semble plausible. Mais une sￜcuritￜ
basï¿œe sur les derniers caractï¿œres du nom, je n'y crois pas un caramel.
>>> Mais ï¿œvidemment plus question de les "includer" avec exï¿œcution
>>> du PHP ensuite, a priori.
>>
>> Hein ? Et pourquoi donc ? Tu as essayￜ aussi et ￜa ne marche pas ???
>> En principe on ï¿œvite de mettre une extension autre que .php pour
>> ï¿œviter qu'ils soient lisibles directement de l'extï¿œrieur, mais le
>> mieux est de les mettres dans un coin de l'arborescence
>> inaccessible ￜ Apache, et dans ce cas tu peux bien les suffixer
>> comme tu veux.
>
> C'est vrai, ￜa ne n'ai pas encore essayￜ. Il n'y a pas de risque parce que
> j'ai un "deny from all" sur toute l'arborescence.
Parfait. Dans ce cas tu peux bien suffixer ces fichiers en .tartempion,
voire ne pas leur mettre de caractￜre ￜ . ￜ du tout (ce qui veut dire
ￜ pas de suffixe ￜ en langage Windows).
> Mais lￜ encore, je ne connais pas assez bien l'ￜme d'Apache pour ￜtre sￜr
> que toute version exï¿œcute un fichier inclus depuis du PHP mï¿œme si
> l'extension n'est pas dï¿œclarï¿œe comme telle...
Gniii ? Quand PHP fait un include(), il ne prï¿œvient pas Apache de ce
qu'il fait. D'ailleurs Apache s'en fout.
Note que beaucoup de programmeurs, pour une raison que j'ignore,
suffixent les scripts PHP inclus en .inc au lieu de .php, et ï¿œa n'a
jamais gￜnￜ ni Apache ni PHP.
>> Je n'ai pas essayￜ avec fopen(), mais avec readfile() je le fais
>> trￜs couramment, sans aucun problￜme. Tu peux dￜjￜ essayer ￜa.
>
> readfile() ne m'arrange pas parce qu'il dï¿œvore le fichier entier, alors que
> mon but est de ne lire que le header de 2 lignes.
Oui, d'accord, mais bon : pour le moment tu es face ￜ un bug que tu ne
comprends pas et dont je soupï¿œonne que la cause soit dans ta maniï¿œre de
faire, et j'essaye de te donner le maximum de pistes pour que te vienne
l'illumination ! Je suis prￜt ￜ parier qu'il arrivera un moment oￜ tu
diras ￜ bon sang mais c'est bien sￜr, c'est parce que j'ai fait ￜa et
ￜa, qu'il s'est passￜ ￜa ￜ, et ￜ ce moment-lￜ tu pourras revenir ￜ fopen
parce que ï¿œa marchera.
> Mais ce que tu dis confirmerait que c'est mon EasyPHP qui fait des
> maniï¿œres...
Non, je ne dis pas ï¿œa. Je parie plutï¿œt pour une combinaison de trucs
dans ta config et dans tes scripts.
> open_basedir aurait pu... En effet j'essaie aussi de mutualiser un moteur
> entre plusieurs sites, et donc je suis amener ￜ utiliser des chemins en
> ../Engine et ../SiteN
Haha ! Dans ce cas, vï¿œrifie si include() et fopen() ne se comportent pas
diffￜremment vis-ￜ-vis des liens symboliques (ￜ raccourcis ￜ en Windows,
sauf erreur).
Par exemple, si tu as un lien de /a vers /b/c, quand tu fais ../Engine
en ï¿œtant sous /a tu pourrais te retrouver soit sous /Engine, soit sous
/b/Engine, selon que le vrai nom a ￜtￜ interprￜtￜ ou pas.
> Mais ï¿œa ne changerait pas de comportement avec l'extension.
Hum. Oui, c'est vrai. ￜ moins que le nom existe dￜjￜ quelque part.
Essaye avec des noms improbables, du genre bluzgrud.txt et bluzgrud.php,
pour ￜviter que le fichier existe dￜjￜ ailleurs.
> C'est vrai que j'utilise des sous-extensions en gï¿œnï¿œral et donc aussi dans
> mes scripts: genre
> Item.script.php pour distinguer de
> Contenu.page.php par exemple.
Oui, mais on s'en fiche.
> Mï¿œme Windows s'en fiche et ne considï¿œre que l'extension finale.
Ah ben lui ne s'en fiche pas, alors. Un fopen ou un include devrait
*vraiment* se fiche de toute extension.
> Mais s'il y a un problï¿œme de codage dans EasyPHP, sait-on jamais...
> C'est vrai qu'en changeant *toute l'extension* en ".txt" j'ai fait
> disparaï¿œtre le point intermï¿œdiaire.
Qui plus est, tu as changￜ la longueur du nom. Sur Windows cela pourrait
faire une diffï¿œrence.
> J'utilise des noms longs et du mix de casse en effet, mais c'est vrai aussi
> avec l'extension qui marche.
Du mix de casse ? Windows ne te trouverait pas un TrucBidule.php quand
tu demandes trucbidule.php, avant de dï¿œcider que tu n'as pas le droit
d'y accï¿œder (alors que trucbidule.php tu aurais le droit si l'autre
n'existait pas) ?
> Bon, tu me rassures lￜ, si c'est normalement possible, je dois avoir un
> problï¿œme avec mes outils de test. Je vais creuser ï¿œa...
J'en suis convaincu.
--
Olivier Miakinen
Mickael Wolff
> Dans le cadre d'un serveur de contenu un peu complexe, j'ai un script qui va
> inclure (@include) un certain nombre d'autres, qui sont donc des PHP,
> mais auparavant il doit rassembler dans une structure des donn�es qui sont
> r�parties dans ces m�mes scripts.
Au vu de la discussion, je pense que vous passez � cot� du probl�me.
include utilises l'include_path pour trouver les includes. fopen ne
l'utilises pas. Par contre, si le safe mode est activ�, des rstrictions
d'ouverture peuvent etre appliqu�es, zlors qu'elles ne s'appliqueront
pas � l'inclusion via les directives d�di�es.
> J'ai v�rifi� que le path est bon et �a marche bien si l'extension n'est pas
> .php, donc j'en d�duis que c'est le serveur qui est configur� pour que les
> PHP ne soient accessibles qu'en ex�cution ?
Il se peut que ce soient les ACL de l'OS qui bloquent. Le syst�me est
plus complexe que les droits POSIX.
> * Une id�e de solution ?
Travailler sous Linux. Ecrire du PHP sous MS Windows, c'est prendre
le risque perdre du temps inutilement avec l'admin sys de MS Windows.
--
Micka�l Wolff aka Lupus Michaelis
http://lupusmic.org
Patrick 'Zener' Brunet
Aaaaarghhhh ! J'ai trouvￜ !
"Olivier Miakinen" <om+...@miakinen.net> a ï¿œcrit dans le message
de news 4acd339f$1...@meta.neottia.net
> Le 07/10/2009 23:04, Patrick 'Zener' Brunet a ï¿œcrit :
>>[...]
Aprï¿œs 30mn de tests systï¿œmatiques,
c'est la honte absolue car ï¿œa crevait les yeux:
Comme je disais:
>> C'est vrai que j'utilise des sous-extensions en gï¿œnï¿œral et donc
>> aussi dans mes scripts: genre
>> Item.script.php pour distinguer de
>> Contenu.page.php par exemple.
>> [...]
>> C'est vrai qu'en changeant *toute l'extension* en ".txt" j'ai fait
>> disparaï¿œtre le point intermï¿œdiaire.
Ben non Zener, c'est plus nul que ï¿œa: ces extensions sont gï¿œnï¿œrï¿œes avec des
macros M4 (prï¿œcompilation du site), et si les deux macros en question
s'appellent
ztm4ScriptExtension et ztm4PageExtension, elles ￜvaluent en fait ￜ
"script.php" et "html.php" !!!!!
Donc finalement Contenu.html.php se laisse ouvrir par un fopen
aussi bien que Contenu.test ou mï¿œme
Fr-Contenu.html.php :o(
Du coup je peux comme je le souhaitais rassembler et traiter tous les
cartouches headers avant de lancer la gï¿œnï¿œration par inclusion normale des
scripts, donc sans dï¿œfiler deux fois les scripts entiers.
Je confirme aussi que ceci marche trï¿œs bien en test (sous Windows):
>> ... j'essaie aussi de mutualiser un moteur
>> entre plusieurs sites, et donc je suis amener ￜ utiliser
>> des chemins en ../Engine et ../SiteN
Il faut encore que je le valide dans un contexte d'hￜbergement partagￜ (sous
un Linux ou Unix) avec les sites dans des sous-rï¿œpertoires d'un mï¿œme
rï¿œpertoire racine qui devraient donc avoir les mï¿œmes droits d'accï¿œs, mï¿œme
s'ils sont pointï¿œs par des noms de domaines diffï¿œrents.
Le but est que le moteur soit partagￜ, histoire de gagner un peu d'espace et
de rendre la maintenance plus facile.
Si ï¿œa pose des problï¿œmes de droits d'accï¿œs, je pourrai toujours copier le
moteur dans le DocumentRoot de chaque site, ï¿œa conservera l'intï¿œrï¿œt de le
dissocier complï¿œtement des contenus dï¿œdiï¿œs, et donc de le rendre
gï¿œnï¿œrique...
Navrￜ de vous avoir fait perdre votre temps avec ce faux-bug, Voilￜ ce que
c'est de faire de l'alimentaire dans la journï¿œe et de la R&D le soir :-/
Et toutes mes excuses aux auteurs de EasyPHP qui me sert pas mal pour
tester...
Il me faudrait aussi un compilo PHP pour valider le code plus formellement
qu'avec Firefox qui ne voit que les instructions effectivement
interprï¿œtï¿œes...
Merci encore pour le support.
Olivier Miakinen
>
> Aaaaarghhhh ! J'ai trouvￜ !
> c'est la honte absolue car ï¿œa crevait les yeux:
J'en ￜtais persuadￜ depuis le dￜbut. Tu vois que j'ai bien fait de te
pousser dans tes derniers retranchements !
J'en ￜtais tellement persuadￜ que j'ai mￜme ￜcrit dans ma derniￜre rￜponse :
<cit.>
Oui, d'accord, mais bon : pour le moment tu es face ￜ un bug que tu ne
comprends pas et dont je soupï¿œonne que la cause soit dans ta maniï¿œre de
faire, et j'essaye de te donner le maximum de pistes pour que te vienne
l'illumination ! Je suis prￜt ￜ parier qu'il arrivera un moment oￜ tu
diras ￜ bon sang mais c'est bien sￜr, c'est parce que j'ai fait ￜa et
ￜa, qu'il s'est passￜ ￜa ￜ, et ￜ ce moment-lￜ tu pourras revenir ￜ fopen
parce que ï¿œa marchera.
</cit.>
Et voilￜ, l'illumination t'est venue.
> Navrￜ de vous avoir fait perdre votre temps avec ce faux-bug, Voilￜ ce que
> c'est de faire de l'alimentaire dans la journï¿œe et de la R&D le soir :-/
Ce n'est pas grave. ￜa m'aurait plus inquiￜtￜ si j'avais cru ￜ un
vrai bug de la fonction fopen(), mais j'avais trop confiance en
cette fonction, que j'utilise (en C) depuis plus de vingt ans,
pour croire qu'elle puisse nous lï¿œcher comme ï¿œa...
Cordialement,
--
Olivier Miakinen
Patrick 'Zener' Brunet
"Olivier Miakinen" <om+...@miakinen.net> a ï¿œcrit dans le message
de news 4ace3fa0$1...@meta.neottia.net
> Le 08/10/2009 21:28, Patrick 'Zener' Brunet a ï¿œcrit :
>>
>> Aaaaarghhhh ! J'ai trouvￜ !
>> [...]
>> c'est la honte absolue car ï¿œa crevait les yeux:
>
> J'en ￜtais persuadￜ depuis le dￜbut. Tu vois que j'ai bien fait de
> te pousser dans tes derniers retranchements !
>
> J'en ￜtais tellement persuadￜ que j'ai mￜme ￜcrit dans ma derniￜre
> rï¿œponse : <cit.>
> Oui, d'accord, mais bon : pour le moment tu es face ￜ un bug que
> tu ne comprends pas
Le pire, c'est que j'ai dￜjￜ vu tellement de trucs vraiment foireux que ￜa
suggￜre des scￜnarios trￜs rￜalistes ￜ base de bugs tordus.
Ceux qui suivent mes aventures sur les newsgroups :o) savent que je pousse
souvent les technologiess dans leurs derniers retranchements, elles-aussi.
Et le pire c'est qu'en expï¿œrimentant pour vï¿œrifier, on trouve ce qu'on
cherche, donc on s'enterre...
> [...]
>> Voilￜ ce que c'est de faire de l'alimentaire dans la journￜe et de
>> la R&D le soir :-/
>
> Ce n'est pas grave. ￜa m'aurait plus inquiￜtￜ si j'avais cru ￜ un
> vrai bug de la fonction fopen(), mais j'avais trop confiance en
> cette fonction, que j'utilise (en C) depuis plus de vingt ans,
> pour croire qu'elle puisse nous lï¿œcher comme ï¿œa...
La fopen() du C, j'ai confiance aussi, mais celle de PHP c'est autre
chose... A vrai dire, le Web et ses "technologies" commencent ￜ pas mal me
sortir par les yeux, parce que le bricolage est toujours plus ou moins
incontournable.
Au fait, quelqu'un connaï¿œtrait un compilo PHP "ï¿œconomiquement accessible",
juste pour valider syntaxiquement le code mï¿œme dans les branches exï¿œcutï¿œes
de maniï¿œre exceptionnelle ? Je veux dire 100% du code ï¿œcrit, je n'ai pas de
gￜnￜration dynamique ￜ coups d'eval ou d'include inconnus ￜ l'avance...
J'ai bien trouvￜ des outils qui ont l'air de faire ￜa, mais avec tout un AGL
derriï¿œre, et donc le prix est dissuasif.
Merci.
Mickael Wolff
> Au fait, quelqu'un connaï¿œtrait un compilo PHP "ï¿œconomiquement accessible",
> juste pour valider syntaxiquement le code mï¿œme dans les branches exï¿œcutï¿œes
> de maniï¿œre exceptionnelle ? Je veux dire 100% du code ï¿œcrit, je n'ai pas de
> gￜnￜration dynamique ￜ coups d'eval ou d'include inconnus ￜ l'avance...
Tu peux y aller violemment : find . -name '*.php' -exec php -l \{\} \;
Tu peux aussi utiliser xdebug pour le code coverage, et utiliser des
tests unitaires pour amￜliorer la fiabilitￜ du code.
--
Mickaï¿œl Wolff aka Lupus Michaelis
http://lupusmic.org