fopen( script.php, rt) => acces refuse

Le
Patrick 'Zener' Brunet
Bonjour.

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
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Olivier Miakinen
Le #20288331
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 ?

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
Le #20297141
Bonsoir.

"Olivier Miakinen" de news 4ac8aabf$
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.

--
Cordialement.

* Patrick BRUNET www.ipzb.fr www.ipzb-pro.com
* E-mail: lien sur http://zener131.eu/ContactMe
Patrick 'Zener' Brunet
Le #20297151
Bonsoir.

Je répond à ça séparément parce que ça risque de déclencher un tollé. Et
pourtant...

"Olivier Miakinen" de news 4ac8aabf$
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
;-)

--
Cordialement.

* Patrick BRUNET www.ipzb.fr www.ipzb-pro.com
* E-mail: lien sur http://zener131.eu/ContactMe
Olivier Miakinen
Le #20298241
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 !

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 :
[...] droits d'accès à ce fichier. Si vous activez le safe mode, ou la
directive open_basedir, d'autres conditions peuvent aussi s'appliquer.

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 #20298231
[Copie et suivi vers fr.comp.usenet.lecteurs-de-news]

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
Le #20311241
Bonsoir.

"Olivier Miakinen" de news 4acaf3dd$
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 :
[...] droits d'accès à ce fichier. Si vous activez le safe mode, ou
la directive open_basedir, d'autres conditions peuvent aussi
s'appliquer.



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.

--
Cordialement.

* Patrick BRUNET www.ipzb.fr www.ipzb-pro.com
* E-mail: lien sur http://zener131.eu/ContactMe
Olivier Miakinen
Le #20312031
Le 07/10/2009 23:04, Patrick 'Zener' Brunet a écrit :

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
Le #20313991
Patrick 'Zener' Brunet wrote:

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
Le #20317791
Bonsoir.

Aaaaarghhhh ! J'ai trouvé !

"Olivier Miakinen" de news 4acd339f$
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.

--
Cordialement.

* Patrick BRUNET www.ipzb.fr www.ipzb-pro.com
* E-mail: lien sur http://zener131.eu/ContactMe
Olivier Miakinen
Le #20318511
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 :
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.

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
Publicité
Poster une réponse
Anonyme