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,
--
Cordialement.
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,
--
Cordialement.
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,
--
Cordialement.
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.
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.
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.
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,
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,
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,
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.
Tu y arrives à ouvrir des PHP avec un fopen toi ?
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.
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.
Tu y arrives à ouvrir des PHP avec un fopen toi ?
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.
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.
Tu y arrives à ouvrir des PHP avec un fopen toi ?
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.
Je répond à ça séparément parce que ça risque de déclencher un tollé.
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...
J'espère que je l'ai mieux réglé cette fois.
[...]
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)
Je répond à ça séparément parce que ça risque de déclencher un tollé.
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...
J'espère que je l'ai mieux réglé cette fois.
[...]
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)
Je répond à ça séparément parce que ça risque de déclencher un tollé.
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...
J'espère que je l'ai mieux réglé cette fois.
[...]
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)
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() !
[...]
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.
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() !
[...]
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.
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() !
[...]
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.
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.
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...
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...
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.
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.
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...
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.
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...
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...
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.
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.
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...
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.
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...
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...
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.
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.
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...
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.
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 ?
* Une idée de solution ?
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.
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 ?
* Une idée de solution ?
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.
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 ?
* Une idée de solution ?
Le 07/10/2009 23:04, Patrick 'Zener' Brunet a écrit :
[...]
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.
... j'essaie aussi de mutualiser un moteur
entre plusieurs sites, et donc je suis amener à utiliser
des chemins en ../Engine et ../SiteN
Le 07/10/2009 23:04, Patrick 'Zener' Brunet a écrit :
[...]
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.
... j'essaie aussi de mutualiser un moteur
entre plusieurs sites, et donc je suis amener à utiliser
des chemins en ../Engine et ../SiteN
Le 07/10/2009 23:04, Patrick 'Zener' Brunet a écrit :
[...]
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.
... j'essaie aussi de mutualiser un moteur
entre plusieurs sites, et donc je suis amener à utiliser
des chemins en ../Engine et ../SiteN
Aaaaarghhhh ! J'ai trouvé !
[...]
c'est la honte absolue car ça crevait les yeux:
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 :-/
Aaaaarghhhh ! J'ai trouvé !
[...]
c'est la honte absolue car ça crevait les yeux:
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 :-/
Aaaaarghhhh ! J'ai trouvé !
[...]
c'est la honte absolue car ça crevait les yeux:
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 :-/