Pourquoi ton script se copie-t-il à travers toute l'arborescence ??
Avais-tu vraiment besoin de ça ? Car cela m'inquiète un peu quant aux failles potentielles de ton script.

Bonjour Sékiltoyai et merci pour ta réponse...

Pour la propagation, tu peux essayer de faire un .htaccess dans le répertoire du script :

Code : Tout sélectionner

rewriteengine On rewriterule ^index.php(.*) index.php$1 [L] rewriterule ^(.*) index.php?path=$1 [L]

Bon, là... ... va falloir m'expliquer un peu tout ça, parece que, en matière de ".htaccess", je suis... comment dire... je suis un parfait ignare

Si tu avais un moment, je voudrais bien connaître le rôle de ce bout de code et, si possible, comprendre un peu sa syntaxe... parce que là... j'y pige nada

Merci à toi... à+

En fait, le rôle de ce .htaccess est de renvoyer toutes les urls de l'arborescence vers le script lui-même. On utilise donc l'URL Rewriting, c'est un module d'apache qui permet de réécrire les urls qui arrivent à ton serveur.

La première ligne du .htaccess sert à activer l'url rewriting. La seconde sert à protéger ton index.php, car apache appele l'url rewriting une fois, effectue la redirection, et l'appele une nouvelle fois, on protège ainsi ton script d'une éventuelle index.php?path=index.php?path=chemin_reel/fichier_reel.png et on permet d'appeler le script directement par son adresse. La troisième ligne effectue la réécriture en elle-même, à savoir qu'il redirige toute l'url vers ton script de cette manière :
URL de départ : /root/chemin_a_ton_htaccess/chemin_a_ton_fichier/fichier.txt
URL d'arrivée : /root/chemin_a_ton_htaccess/index.php?path=chemin_a_ton_fichier/fichier.txt

N'ayant jamais vraiment fait de rewriting auparavant, j'ai tout de même tenu à tester :
Mon url de départ était : http://localhost/test_rewrite/dossier1/image.png
Et à l'arrivée, j'obtiens path=/dossier1/image.png
Avec ce index.php :

<?php
echo $_SERVER['QUERY_STRING'];
?>

Donc ca a l'air de marcher.

On peut aussi imaginer une configuration dans laquelle le script n'est pas dans le dossier du .htaccess (le .htaccess est la base de l'arborescence à faire passer par ton script), et écrire un tel .htaccess : Dans ce cas, on suppose que le script n'est pas dans l'arborescence. Ca peut être utile lorsque les fichiers à parcourir sont des fichiers php.
Par exemple, j'ai cette arborescence : J'écris ce .htaccess : ou bien celui ci : (A tester)

Sinon sur l'AppleScript, personnellement je n'ai jamais vraiment réussir à faire ce que je voulais avec…
Je trouve la doc vraiment pauvre :-/

Pourquoi ton script se copie-t-il à travers toute l'arborescence ??
Avais-tu vraiment besoin de ça ?

Pour que lorsque tu fais http://domain.tld/path/ , il ne te liste pas le répertoire avec le handler par défaut de apache mais qu'il appelle le script, d'où la nécessité de copier récursivement pour profiter des index…
C'est pour cela que je lui propose la solution du .htaccess…

Rebonjour Sékiltoyai

Code : Tout sélectionner

rewriteengine On rewriterule ^index.php(.*) index.php$1 [L] rewriterule ^(.*) index.php?path=$1 [L]

En fait, le rôle de ce .htaccess est de renvoyer toutes les urls de l'arborescence vers le script lui-même. On utilise donc l'URL Rewriting, c'est un module d'apache qui permet de réécrire les urls qui arrivent à ton serveur.

La première ligne du .htaccess sert à activer l'url rewriting. La seconde sert à protéger ton index.php, car apache appele l'url rewriting une fois, effectue la redirection, et l'appele une nouvelle fois, on protège ainsi ton script d'une éventuelle index.php?path=index.php?path=chemin_reel/fichier_reel.png et on permet d'appeler le script directement par son adresse. La troisième ligne effectue la réécriture en elle-même, à savoir qu'il redirige toute l'url vers ton script de cette manière :
URL de départ : /root/chemin_a_ton_htaccess/chemin_a_ton_fichier/fichier.txt
URL d'arrivée : /root/chemin_a_ton_htaccess/index.php?path=chemin_a_ton_fichier/fichier.txt

N'ayant jamais vraiment fait de rewriting auparavant, j'ai tout de même tenu à tester :
Mon url de départ était : http://localhost/test_rewrite/dossier1/image.png
Et à l'arrivée, j'obtiens path=/dossier1/image.png
Avec ce index.php :

<?php
echo $_SERVER['QUERY_STRING'];
?>

Donc ca a l'air de marcher.

Wouw ! ça c'est de l'explication ! ... merci beaucoup

Donc, si je comprends bien le principe, il s'agit de demander au server, grace au fichier ".htaccess", d'attraper au vol toutes les requettes Url et les diriger directement vers le script, en mettant le chemin d'accès relatif demandé dans une variable Url... ce que le script doit récupérer à son tour pour construire la liste d'éléments dans le dossier demandé... c'est ça ou j'ai loupé une marche ?

Ok, si c'est ça, alors je dois distribuer le script avec ce fichier ".htaccess", ou alors imaginer une fonction dans le script qui le créerait automatiquement (si c'est possible bien-sûr)... ton idée est vraiment séduisante... =D>

Maintenant, comment résoudre la siutation où dans les dossiers à lister existent des fichiers à visualiser, qui n'ont pas à être rédirigés vers le script ?

Par exemple, j'ai une arborescence de ce type :
Donc, si je demande "www.monsite.fr/pages/", d'accord, je veux bien que ce repertoire soit listé par défaut par le script "DirList", du coup la rédirection du fichier ".htaccess" serait OK !

De même, si je demande "www.monsite.fr/pages/images/", là aussi, je trouve bien que le script soit appelé pour lister ce sous-dossier...

Mais, qu'en est il si je demande "www.monsite.fr/pages/blog/" ou "www.monsite.fr/pages/blog/index.php" ?

Là il ne faudrait pas que la redirection passe par le script "DirList", il faut que le fichier "indix.php" du blog puisse s'afficher normalement... non ?

Bref, l'idée me plaît bien, faut que je creuse pour voir ce qui est techniquement faisable et ce qui est ergonomiquement judicieux de faire...

Quant à la possibilité des lister des répertoires en déhors de l'arborescence où se trouve le script, je ne sais pas si c'est une bonne idée, je m'interroge vraiment sur la pertinance d'un tel choix... je ne sais pas, tu aurais un avis sur la question ?

En fait, sur la version de "DirList" de dév. que j'ai chez moi, j'ai fais le choix de ne jamais lister les répertoires qui se trouvent "au dessus" du script, autrement dit, le script ne ferait que parcourir et lister l'arborescence des dossier uniquement en descendant dans la hiérarchie à partir du répertoire où il se trouve, jamais en la remontant...

Je ne sais pas si c'est un "bon" choix, mais il m'est paru important de fixer une limite en guise de frontière de sécurité... à voir...

Merci en tout cas Sékiltoyai pour toutes ces explications, on ne peut plus claires et instructives... dès que j'aurais un moment, je vais explorer sérieusement cette piste, elle peut être en effet la solution à mes problèmes de propagation du script...

à+

Re...

Sinon sur l'AppleScript, personnellement je n'ai jamais vraiment réussir à faire ce que je voulais avec…
Je trouve la doc vraiment pauvre :-/

Oui, tu n'a pas tort, mais il y a désormais suffisament de sources d'infos sur internet pour au moins faire ces premiers pas... voici un lien qui t'en donnera un certain nombre (certains liens sont morts, mais dans l'ensemble tu trouveras certainement ton bonheur ) :

http://forums.macfr.com/Ressources-Appl ... 20018.html

à+

il y a désormais suffisament de sources d'infos sur internet pour au moins faire ces premiers pas...

C'est surtout une référence du langage et de toutes les fonctions qu'il me faudrait…

Re...

il y a désormais suffisament de sources d'infos sur internet pour au moins faire ces premiers pas...

C'est surtout une référence du langage et de toutes les fonctions qu'il me faudrait…

La documentation de référence se trouve ici : AppleScript Fundamentals (en)

La traduction française se trouve par là : Guide AppleScript

Sinon, petite remarque, dans AS il n'y a pas un ensemble complèt de fonctions predéfinies comme pour Php par exemple, mais il existe des extensions (nommées "compléments de pilotage" ou "Osaxs") qui ajoutent un certain nombre de fonctionnalités non présentes par défaut dans le langage.

Bon, ce n'est pas ici le meilleur lieu pour parler d'AppleScript, mais si le sujet t'intéresse vraiment, on pourrait se retrouver sans soucis sur d'autres espaces de discussion dédiés à ce langage, tiens-moi au courant Stp...

à+

Donc, si je comprends bien le principe, il s'agit de demander au server, grace au fichier ".htaccess", d'attraper au vol toutes les requettes Url et les diriger directement vers le script, en mettant le chemin d'accès relatif demandé dans une variable Url... ce que le script doit récupérer à son tour pour construire la liste d'éléments dans le dossier demandé... c'est ça ou j'ai loupé une marche ?

Oui

Ok, si c'est ça, alors je dois distribuer le script avec ce fichier ".htaccess", ou alors imaginer une fonction dans le script qui le créerait automatiquement (si c'est possible bien-sûr)... ton idée est vraiment séduisante... =D>

Tu peux faire un script d'installation ou une administration dans laquelle tu choisis les dossiers à inclure ou exclure et qui génère le .htaccess à la racine de l'arborescence à parcourir.

Maintenant, comment résoudre la siutation où dans les dossiers à lister existent des fichiers à visualiser, qui n'ont pas à être rédirigés vers le script ?

Par exemple, j'ai une arborescence de ce type :

Code : Tout sélectionner

monsite/ .htaccess dirlist.php index.html pages/ blog/ index.php images/ logo.jpg page1.html page2.html etc

Donc, si je demande "www.monsite.fr/pages/", d'accord, je veux bien que ce repertoire soit listé par défaut par le script "DirList", du coup la rédirection du fichier ".htaccess" serait OK !

De même, si je demande "www.monsite.fr/pages/images/", là aussi, je trouve bien que le script soit appelé pour lister ce sous-dossier...

Mais, qu'en est il si je demande "www.monsite.fr/pages/blog/" ou "www.monsite.fr/pages/blog/index.php" ?

Là il ne faudrait pas que la redirection passe par le script "DirList", il faut que le fichier "indix.php" du blog puisse s'afficher normalement... non ?

Comme j'ai supprimé le index.php tout à l'heure. A savoir que la dernière règle est la règle de réécriture réelle, et juste avant, il y avait une règle pour exclure le index.php.
Dans ton cas : Lors de la lecture, si tu demandes pages/blog/index.php apache exécute la première ligne, il démarre le mécanisme de réécriture, ensuite, la deuxième ligne, il ne réécrit rien car l'expression régulière ne correspond pas à ton url, la troisième ligne, il trouve une concordance et réécrit l'url en pages/blog/index.php (donc laisse tel quel), et vu que je lui ai mis le flag [L], il s'arrête là et n'exécute pas la dernière règle. Tu as exclu ta sous arborescence de l'arborescence du script.
Cependant, il faut être conscient que si tu adoptes la solution du .htaccess, tu auras un script puissant, mais utilisable exclusivement sur un serveur apache…

Quant à la possibilité des lister des répertoires en déhors de l'arborescence où se trouve le script, je ne sais pas si c'est une bonne idée, je m'interroge vraiment sur la pertinance d'un tel choix... je ne sais pas, tu aurais un avis sur la question ?

En fait, sur la version de "DirList" de dév. que j'ai chez moi, j'ai fais le choix de ne jamais lister les répertoires qui se trouvent "au dessus" du script, autrement dit, le script ne ferait que parcourir et lister l'arborescence des dossier uniquement en descendant dans la hiérarchie à partir du répertoire où il se trouve, jamais en la remontant...

Je ne sais pas si c'est un "bon" choix, mais il m'est paru important de fixer une limite en guise de frontière de sécurité... à voir...

L'important, ce n'est pas tant la position de ton script que la position et les règles définis dans ton .htaccess, dans la mesure où c'est ton .htaccess et lui seul qui définit l'arborescence, c'est à dire que toutes les requètes qui sont dans l'arborescence définie par ton .htaccess seront renvoyées vers ton script, et les autres non. La position de ton script n'a donc aucune importance stratégique, tant qu'il est capable lui même de lister les dossiers.
Par contre, il est vrai que si tu places ton script dans un autre dossier que la racine de l'arborescence à traiter, tu devras d'une part générer un .htaccess adéquat pour que les bonnes url soient réécrites, et d'autre part enregistrer la configuration de manière à ce que ton script traite l'arborescence réelle et non l'arborescence qui est sous lui, et aussi de manière à ce qu'un malin ne s'amuse pas à bluffer le script en l'appelant directement par dirlist.php?path=chemin_interdit/
Mais l'avantage de dissocier le script de l'arborescence c'est que tu marques la différence entre les deux, et tu t'assures que on ne puisse absolument pas lister ton fichier.

Bonjour Sékiltoyai et merci pour ta réponse

Euh... c'est chez moi que ça déconne ou ton message est passé en double ?

Ok, si c'est ça, alors je dois distribuer le script avec ce fichier ".htaccess", ou alors imaginer une fonction dans le script qui le créerait automatiquement (si c'est possible bien-sûr)... ton idée est vraiment séduisante... =D>

Tu peux faire un script d'installation ou une administration dans laquelle tu choisis les dossiers à inclure ou exclure et qui génère le .htaccess à la racine de l'arborescence à parcourir.

Oui, en effet, j'ai déjà commencé à faire une petite page d'administration, je pourrais ajouter cette fonctionnalité... quant à faire un script d'installe, même si l'idée est certainement à creuser, ça me paraît un peu trop pour l'instant pour un petit projet de ce type...

Maintenant, comment résoudre la siutation où dans les dossiers à lister existent des fichiers à visualiser, qui n'ont pas à être rédirigés vers le script ?
...

Comme j'ai supprimé le index.php tout à l'heure. A savoir que la dernière règle est la règle de réécriture réelle, et juste avant, il y avait une règle pour exclure le index.php.
Dans ton cas :

Code : Tout sélectionner

rewriteengine On rewriterule ^index.php(.*) index.php$1 [L] rewriterule ^pages/blog/(.*) pages/blog/$1 [L] rewriterule ^(.*) index.php?path=$1 [L]

Lors de la lecture, si tu demandes pages/blog/index.php apache exécute la première ligne, il démarre le mécanisme de réécriture, ensuite, la deuxième ligne, il ne réécrit rien car l'expression régulière ne correspond pas à ton url, la troisième ligne, il trouve une concordance et réécrit l'url en pages/blog/index.php (donc laisse tel quel), et vu que je lui ai mis le flag [L], il s'arrête là et n'exécute pas la dernière règle. Tu as exclu ta sous arborescence de l'arborescence du script.

Merci pour toutes ces infos, qui m'ont permis de comprendre, en plus, que la syntaxe de ces lignes n'est après tout que des "simples" rechercher/remplacer à la sauce "expressions régulières", ce que je n'avais pas bien compris précédemment... c'est vraiment nickel tes explications, Merci !

Quant à la possibilité des lister des répertoires en déhors de l'arborescence où se trouve le script, je ne sais pas si c'est une bonne idée, je m'interroge vraiment sur la pertinance d'un tel choix... je ne sais pas, tu aurais un avis sur la question ?
...

L'important, ce n'est pas tant la position de ton script que la position et les règles définis dans ton .htaccess, dans la mesure où c'est ton .htaccess et lui seul qui définit l'arborescence, c'est à dire que toutes les requètes qui sont dans l'arborescence définie par ton .htaccess seront renvoyées vers ton script, et les autres non. La position de ton script n'a donc aucune importance stratégique, tant qu'il est capable lui même de lister les dossiers.
Par contre, il est vrai que si tu places ton script dans un autre dossier que la racine de l'arborescence à traiter, tu devras d'une part générer un .htaccess adéquat pour que les bonnes url soient réécrites, et d'autre part enregistrer la configuration de manière à ce que ton script traite l'arborescence réelle et non l'arborescence qui est sous lui, et aussi de manière à ce qu'un malin ne s'amuse pas à bluffer le script en l'appelant directement par dirlist.php?path=chemin_interdit/
Mais l'avantage de dissocier le script de l'arborescence c'est que tu marques la différence entre les deux, et tu t'assures que on ne puisse absolument pas lister ton fichier.

En effet, ton analyse est pertinante, ceci dit, dans un site où la hiérarchie des dossiers et fichiers est amenée à changer plus ou moins régulièrement, il faudra donc être attentif pour mettre à jour les différents régles dans tous les ".htaccess" concernés, ce qu'implique une maintenance pas toujours évidente à tenir, surtout pour ceux qui ne sont pas habitués aux subtilités du langage utilisé...

Bref, la piste me paraît toujours très intéressante, dès que j'aurais un peu de temps pour rependre le projet, je vais l'explorer et faire quelques tests, afin de voir si c'est jouable et si ce n'est pas trop contraignant à mettre en oeuvre...

En tout cas, encore mille mercis pour toutes ces explications, très claires et fort instructives, je n'y connaissais rien aux fichiers ".htaccess", maintenant je suis un peu moins pommé qu'avant...

Sinon, je me permet de revenir un instant sur cette petite remarque :

Cependant, il faut être conscient que si tu adoptes la solution du .htaccess, tu auras un script puissant, mais utilisable exclusivement sur un serveur apache…

Ok, c'est à dire que seuls les serveurs tournant sous Apache savent gérer les fichiers de type ".htaccess"... c'est bien ça ?

Si c'est le cas, alors, à ton avis, celà est trop pénalisant ou pas ?

Autrement dit, selon toi, à la louche, quelle proportion de serveurs tournet sous Apache ?

Car s'il n'y a qu'une très faible proportion, ça veut alors dire que le script à la mode ".htaccess" concernera finalement que peu de personnes... non ?

Bref, l'idée pour moi de proposer cette contribution, qui à la base, je le rapelle, a était faite pour un usage perso, est qu'elle puisse éventuellement servir au plus grand nombre de personnes (enfin, c'est plutôt un souhait... bien rêveur quand-même, je le reconnais volontier )...

Bon, sur ce, dès que j'aurais du nouveau, je ne manquerai pas de vous tenir au courant... encore merci Sékiltoyai pour le temps consacré à expliquer la technique du ".htaccess", je te dirais si c'est finalement cette solution que j'aurais retenu pour la prochaine version du script...

Merci... à+

Ok, c'est à dire que seuls les serveurs tournant sous Apache savent gérer les fichiers de type ".htaccess"... c'est bien ça ?

Si c'est le cas, alors, à ton avis, celà est trop pénalisant ou pas ?

Autrement dit, selon toi, à la louche, quelle proportion de serveurs tournet sous Apache ?

Car s'il n'y a qu'une très faible proportion, ça veut alors dire que le script à la mode ".htaccess" concernera finalement que peu de personnes... non ?

Voilà tout à fait.
Mais ce n'est pas trop pénalisant vu que la majorité ( dans les 70% ) des serveurs utilisent apache, et la plupart d'entre eux autorisent le rewriting, donc tu touches encore la majeure partie des gens.
Je te disais ça surtout pour que tu sois conscient que ce script ne tournera pas sur IIS…

Bonjour

Autrement dit, selon toi, à la louche, quelle proportion de serveurs tournet sous Apache ?

Mais ce n'est pas trop pénalisant vu que la majorité ( dans les 70% ) des serveurs utilisent apache, et la plupart d'entre eux autorisent le rewriting, donc tu touches encore la majeure partie des gens.
Je te disais ça surtout pour que tu sois conscient que ce script ne tournera pas sur IIS…

Ok, je suis plutôt rassuré, mais il va falloir quand-même que j'introduise un petit test dans les script pour s'assurer que le serveur dans lequel il tourne est bien de type Apache et que le "rewrating" est bien activé... et dans le cas contraire soit avertir l'utilisateur que le script ne peut pas tourner efficacement ou trouver une technique pour adapter son fonctionnement selon le contexte... bref, faut que je creuse la question...

Sinon, à première vue, pour le test du serveur, je pense qu'avec les variables globales "$_ENV" ou "$_SERVER" je devrais trouver l'info nécessaire, mais pour le "rewriting", là je ne sais pas trop :/ ... il y a peut-être un moyen pour interroger le serveur afin d'obtenir cette info, faut voir... en tout cas, le moment venu, je me pencherai sérieusement sur la question... en attendant, si jamais tu as des pistes, n'hésites pas

Merci encore Sékiltoyai... à+

Tu as la fonction apache_get_modules() qui te renvoie la liste des modules chargés par le serveur apache. Le seul problème, c'est que cette fonction n'est disponible que lorsque php est installé en tant que module du serveur et ne marche pas pour les installations en CGI…

Sinon tu peux te faire ceci :

.htaccess : dirlist/test.txt :
test

dirlist/dirlist.php :

<?php
(...)
function test_rewrite()
{
   $handle = fopen('http://' . $_SERVER['HTTP_HOST'] . dirname($_SERVER['PHP_SELF']) . 'test.dirlist', 'r');
   $ret = (fread($handle, 5)=='test');
   fclose($handle);
   return $ret;
}
(...)
?>

Après tu adaptes à ta sauce…

Bonjour Sékiltoyai

Sinon tu peux te faire ceci :

[...]

Après tu adaptes à ta sauce…

Très très astucieux d'utiliser la fonction même de "rewrating" sur une requête "bidon" afin de vérifier si ça fonctionne... pas mal !

Bon, comme tu l'a suggéré, j'ai un peu adapté ça à ma sauce, surtout dans l'idée d'éviter d'avoir un fichier texte uniquement pour le test, et essayer plutôt d'utiliser le script lui-même... enfin bon, chez moi, en local, ça a l'air de bien fonctionner, mais lorsque j'ai voulu le tester sur mon site perso, hébergé par Free, là ça ne marche plus ... j'ai un peu regardé dans les pages d'info du fournisseur, mais je n'ai trouvé aucune explication sur la manière de faire du "rewraiting" chez eux... je me demande seulement s'ils n'ont pas désactivé cette option... va savoir :/

Sinon, voici le bout de code de test que j'ai fais, n'hésites pas à me signaler toute erreur ou mauvais choix de ma part :

function f_rw_test() {
	session_start(); 
	list($theHtaccess, $theScript, $rwOk) = array('.htaccess', basename(__FILE__), 0);
	if (isset($_SESSION['rwok']) && $_SESSION['rwok']) { 
		$rwOk = 1;
	} elseif (isset($_GET['rwtest']) && $_GET['rwtest']) {
		$_SESSION['rwok'] = 1;
		$rwOk = 1;
	} elseif (file_exists($theHtaccess)) {
		header("Location: $theScript");
	} else {
		$theRewriteTest = "RewriteEngine on
RewriteRule $theScript $theScript?rwtest=1 [L]";
		$ok = f_write_file($theHtaccess, $theRewriteTest);
		header("Location: $theScript");
	}
	return $rwOk;
}

Bon, pour l'instant ce code mémorise l'activation du "rewraiting" dans une variable de session, mais dans le script final cette info sera sauvegardée dans un fichier de configuration, qui de toutes manières sera nécessaire pour enregistrer les différents paramétrages du script...

Voilô... je te remerci encore une fois pour toutes tes explications et le temps que tu as conscré à trouver une solution au problème de propagation de mon petit projet... j'espère pouvoir m'y pencher sérieusement dans les jours à venir...

à+