[Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

Elzen · Le 21/10/2009, à 12:41

Salut les gens,
J'ai eu une petite idée pour le développement de mon site qui pourrait grandement me faciliter la vie, mais je ne sais pas du tout comment faire, et j'ai du mal à faire une recherche efficace sur le sujet. Ceci dit, c'est peut-être plus du paramétrage que du développement, donc désolé si je n'ai pas posté au bon endroit.

Ceux qui ont déjà jeté un œil à mon site ont sûrement déjà remarqué mon panneau d'accueil anti-intrusions. Le principe de fonctionnement est simple : il faut avoir une session ouverte (en tant qu'invité ou en tant qu'utilisateur enregistré) pour entrer, ce qui empêche les robots d'indexation et quelques autres de faire leur boulots.

Le problème, c'est que ce code est intégré directement dans le code PHP de mes pages, donc si je veux rapidement rajouter un petit fichier HTML, une image ou quelque chose d'autre du même genre, la protection ne s'y applique pas. Or, je suis en train de refaire le site pour limiter au maximum les traitements inutiles effectués par le serveur, et donc pour ça, je voudrais qu'un maximum de fichiers HTML soient autogénérés à la place des scripts PHP qui s'exécutent à chaque fois.

Je voudrais donc savoir comment je pourrais faire pour que mon apache, chaque fois qu'on lui demande un fichier dans un répertoire donné, commence par vérifier si ce répertoire contient un script à exécuter (qui porterait par exemple toujours le même nom, genre "verif.php") avant d'aller voir le fichier demandé. Quel que soit le fichier (HTML, image, son ou autre).
Comme ça, le script peut vérifier que la session est bien correctement ouverte, et bloquer l'utilisateur en lui renvoyant le panneau d'accueil si ce n'est pas le cas. Mais il peut également vérifier que le fichier demandé existe bien, et le générer dans le cas contraire.

Je précise que mon serveur est sur une machine perso, donc j'ai accès à toute la config en cas de besoin.

Est-ce que quelqu'un aurait des pistes à m'indiquer ?

Edit : résolu. Voir plus bas.

Dernière modification par ArkSeth (Le 22/10/2009, à 13:22)

yopploup · Le 21/10/2009, à 13:13

Salut,

Si j'ai bien compris, tu essaye de te protéger des robots.
Si il s'agit de robots indexeurs, rien de bien méchant. Il robots.txt à la racine de ton site qui contient:

User-agent: *
Disallow: /

Si maintenant, tu souhaites interdire tout robots, qui flood / indexe, rien de mieux que de faire ta propre solution:

Il faut penser professionnel. Ton site doit être entièrement DYNAMIQUE, pas de fichiers .HTML dans le FTP, mais exclusivement des templates, avec cache, etc...
En ce sens, tu pourras aisément modifier une balise méta, sur l'ensemble de ton site.

Tu appliqueras en un clic, une balise meta d'anti robots, sur toutes tes pages.
Pour les robots floodeurs, il est inutile de vouloir protéger l'ensemble de son site.
Le formulaire de contact seul, avec un système innovant crée par toi même et non repompé fera l'affaire.

Maintenant, rien ne t'empêche de créer une session par javascript externe ( illisible par les robots ). Si également tu veux empêcher l'accès au images, simule un CDN. Tu envoies les données DATAs ( IMG / JS / CSS / ... ) par PHP, de manière dynamique. Ainsi tu peux faire au début de ton script, une vérification de validé de sessions précedemment envoyé à l'initialisation du site, autrement dit depuis la page d'accueil par exemple.

tshirtman · Le 21/10/2009, à 14:12

dans un autre sujet, ArkSeth a écrit :

D'ailleurs, à la limite, si ces messieurs fans de python (ou de n'importe quel autre langage aisément utilisable) veulent bien m'expliquer comment faire la manip' mentionnée dans le sujet sus-cité et m'expliquer comment on gère certaines choses (les sessions, notamment) dans leur langage à eux, j'veux éventuellement bien l'utiliser à la place du PHP, vu que vous n'êtes rien que de vils intolérants anti-PHP qu'est pourtant un langage très bien

faire un serveur http en python (attention, ne marchera pas si apache est lancé, à moins de lui donner un autre port)

def run(server_class=BaseHTTPServer.HTTPServer,
        handler_class=BaseHTTPServer.BaseHTTPRequestHandler):
    server_address = ('', 80)
    httpd = server_class(server_address, handler_class)
    httpd.serve_forever()

http://docs.python.org/library/basehttpserver.html

il faudrait que tu regarde le code de cette méthode pour ajouter les tests que tu veux... et l'appeler après, tu passe la fonction qui fait tout ça dans le code plus haut à sa place, je ne sais pas si c'est simple par ce que j'ai pas essayé, mais je pense qu'avec un peu de chance ça peut être assez facile .

http://docs.python.org/library/basehttpserver.html#BaseHTTPServer.BaseHTTPRequestHandler

après je pense que quand le fichier est à générer tu devra appeler dire à python d'appeler php en ligne de commande et sauvegarder le résultat... ça doit pas être bien méchant. (à moins que tu veuille te coder un template python qu'il te suffira d'appeler pour générer tes pages

Dernière modification par tshirtman (Le 21/10/2009, à 14:17)

rmy · Le 21/10/2009, à 14:21

ArkSeth a écrit :

je voudrais qu'un maximum de fichiers HTML soient autogénérés à la place des scripts PHP qui s'exécutent à chaque fois.

Je ne comprends pas bien ça...

Tu peux-être plus précis/clair ? Ça m'aiderait à t'aider

Pour moi, le HTML est généré par du php en l'occurence. Qu'est-ce qu'un HTML "autogénéré" ? Généré une fois pour toutes par ton php et appelé directement ensuite si la session n'est pas fermée ?

tshirtman · Le 21/10/2009, à 14:23

Il veux un genre de cache en fait... quand on lui demande un fichier (html) si il l'a, il le donne, s'il il ne l'a pas il le génère avec les fichiers php...

Bon en même temps c'est vrai que cache à apache pourrait suffire

Elzen · Le 21/10/2009, à 17:06

yopploup a écrit :

Si j'ai bien compris, tu essaye de te protéger des robots.

Le problème n'est pas là : ça, j'y arrive déjà très bien (et au passage, ce que je veux, ce n'est pas seulement ne pas être indexé, c'est que mes données ne se retrouvent pas dans les ordinateurs de Google et consorts, parce que c'est mes données à moi et pas les leurs. Je suis peut-être un peu parano sur les bords, mais avec un robots.txt, on a aucune assurance qu'ils ne mémorisent pas tout chez eux, même s'ils ne les affichent pas dans les résultats de recherche. Quand une entreprise affiche clairement comme but de centraliser tout le savoir de l'humanité dans ses machines, je m'accorde le droit de m'en méfier). Ce que je voudrais, c'est plutôt adapter ma solution actuelle à une autre manière de gérer le site.

yopploup a écrit :

Il faut penser professionnel.

Sans vouloir te vexer, je crois que cette phrase n'a aucun sens Ou bien en a plusieurs contradictoires les uns avec les autres, parce qu'heureusement, tous les professionnels ne pensent pas pareil (et il y a des amateurs qui pensent mieux leurs sites que des professionnels, heureusement aussi).

yopploup a écrit :

Si également tu veux empêcher l'accès au images, simule un CDN. Tu envoies les données DATAs ( IMG / JS / CSS / ... ) par PHP, de manière dynamique. Ainsi tu peux faire au début de ton script, une vérification de validé de sessions précedemment envoyé à l'initialisation du site, autrement dit depuis la page d'accueil par exemple.

Le problème de cette méthode est qu'il faut soit que tous mes fichiers contiennent l'en-tête PHP approprié, soit que les données soient dans un autre endroit du disque dur (inaccessible depuis l'extérieur) et que je fasse un gros script PHP qui fasse un genre de proxy. Or je voudrais que l'accès aux données se passe de manière transparente pour en faciliter l'accès des deux côtés (depuis le net, et en local pour l'administration).

tshirtman a écrit :

faire un serveur http en python (attention, ne marchera pas si apache est lancé, à moins de lui donner un autre port)

Disons que c'est pas que cette solution ne soit pas élégante, mais je ne suis pas sûr d'avoir l'envie et les connaissances (et je suis sûr de ne pas avoir le temps) de recoder tout moi-même, même si ce serait le meilleur moyen d'avoir exactement ce que je veux Tant qu'à faire, j'aimerais bien réutiliser ce qui existe déjà, si ça peut être utilisé correctement ^^

rmy a écrit :

Tu peux-être plus précis/clair ? Ça m'aiderait à t'aider

C'est vrai que je ne suis pas hyper-précis, j'vais essayer de détailler un peu la manière dont j'ai pensé le truc.

C'est toujours dans la continuité de ma structure actuelle, à savoir un système de blog/forum uniquement avec des fichiers, sans base de données. Le but du jeu étant d'obtenir un système qui permette d'administrer le site avec le plus possible de possibilités uniquement à l'aide d'un gestionnaire de fichiers et d'un éditeur de texte.

Chaque sujet(|thread|fil de discussion) du forum est stoqué sur le disque comme un répertoire contenant l'ensemble de ses messages. Lesquels messages sont pour l'instant constitués de deux fichiers, l'un contenant toutes les méta-informations (auteur, date, etc.), et l'autre contenant le corps du message proprement dit (j'ai fait comme ça parce que c'était plus simple, mais je réunirai peut-être les deux en un seul fichier, 'faut voir. Enfin bref). Le répertoire contient également lui-même un fichier contennant les infos dont il y a besoin (titre du sujet, créateur, état (ouvert ou fermé), tout ça).
Actuellement, il y a un script qui, après avoir vérifié que la session est ouverte, parcours le répertoire pour retrouver l'ensemble des messages, et génère l'affichage au fur et à mesure. Il faut donc relire tous les fichiers à chaque fois que l'on demmande à afficher la page.

Histoire de limiter un peu la charge serveur, je vais faire en sorte qu'au lieu de générer la page juste pour le visiteur qui l'a demandé, le script crée un fichier HTML dans lequel il génère la page, puis renvoie ce fichier au visiteur. Ainsi, le sujet|thread sera accessible directement sans avoir besoin de relire l'ensemble du répertoire. L'avantage sera aussi que ce fichier HTML ne nécessitera pas de serveur web, et que donc je n'aurai qu'à copier les fichiers sur un autre ordinateur sur lequel apache n'est pas installé pour pouvoir à la fois faire une sauvegarde du site et pouvoir visualiser tout ce dont j'ai besoin.

Mais pour que le truc soit vraiment efficace, il faudra quand même qu'un script rapide soit appelé à chaque fois qu'un visiteur du site demande une page pour vérifier 1- que la session est bien ouverte et 2- qu'il n'y a pas eu de nouvelle réponse dans le sujet qui demanderait de réécrire le fichier HTML.

C'est un peu plus clair comme ça ?

rmy · Le 21/10/2009, à 18:39

Bah je crois que tu viens de te trouver la solution. Non ?:P

Elzen · Le 21/10/2009, à 18:46

Bah... non.

ArkSeth a écrit :

Mais pour que le truc soit vraiment efficace, il faudra quand même qu'un script rapide soit appelé à chaque fois qu'un visiteur du site demande une page pour vérifier 1- que la session est bien ouverte et 2- qu'il n'y a pas eu de nouvelle réponse dans le sujet qui demanderait de réécrire le fichier HTML.

C'est justement pour demander comment faire ça que j'ai créé ce sujet

rmy · Le 21/10/2009, à 19:16

Alors tel que tu l'expliques, je dirais un seul fichier php dans ton site, tout les documents et arborescence des dossiers dont tu parles dans un sous dossier protégé par un .htaccess.

Ce fichier php s'occupe de vérifier si la session est valide et d'afficher les pages html déjà générées... J'ai l'impression que tu déplaces le problème : à mon avis c'est lors d'une réponse à un sujet qu'il faut regénérer la page automatiquement et ça évite d'avoir à vérifier à l'affichage si celle-ci doit l'être...

Si tu veux vraiment le faire, et si j'ai bien compris sans BDD, alors je pense qu'après vérif de la session il faut que tu stockes en variable de session les timestamp de création de pages déjà générées. Ainsi avant chaque affichage de page tu vérifies si la page a besoin d'être regénérée et tu remets à jours éventuellement : la page, la variable de session, le fichier des timestamps de création. (Mais qu'est-ce que ça me paraît plus lourd que de régénérer à chaque modif/création de message)

Ensuite, ce script php appelle la page désirée en include. Attention ici à la fameuse faille de sécurité du même nom...

Elzen · Le 21/10/2009, à 19:44

Pour vérifier s'il y a besoin ou pas de regénérer, je passe par un fichier vide qui sert de témoin. Ce fichier est créé automatiquement lorsque l'on génère la page, et supprimé automatiquement lorsque l'on poste une nouvelle réponse ou qu'on modifie un message existant.
De cette manière, côté administration, je peux ajouter ou modifier manuellement du contenu via le navigateur de fichier, et je n'ai qu'à supprimer manuellement le fichier témoin pour forcer le rafraîchissement.

Ceci dit, c'est vrai que je pourrais aussi faire en sorte que la génération se fasse lors de la réponse, auquel cas il faudrait plutôt que je lance manuellement le script si j'ajoute du contenu à la main. Ça peut être plus pratique, en effet. Dans ce cas, il faudrait "juste" que mon script vérifie si la session est démarrée, et si l'utilisateur a accès à la page en question.

rmy a écrit :

Alors tel que tu l'expliques, je dirais un seul fichier php dans ton site, tout les documents et arborescence des dossiers dont tu parles dans un sous dossier protégé par un .htaccess.

C'est grosso-modo comme ça que je procède actuellement, mais je préférerais que l'arborescence via le net corresponde à l'arborescende réelle, ce serait plus pratique.

yopploup · Le 21/10/2009, à 20:29

Sans vouloir te vexer, je crois que cette phrase n'a aucun sens

Ce que je voulais dire c'est qu'aucun site PRO, n'a de page intermédiaire dès la page d'accueil, ce qui est très moche. Puisque personne ne le fait, c'est qu'il y a une raison, autrement dit une solution propre

Le problème de cette méthode est qu'il faut soit que tous mes fichiers contiennent l'en-tête PHP approprié

Un problème pas vraiment non ... il y a 6 types de fichiers maximum à tout cassé dans ton site... que j'ai sous les yeux !

soit que les données soient dans un autre endroit du disque dur (inaccessible depuis l'extérieur)

C'est faux, il ne s'agit pas de mettre les données hors de la racine web.
D'ailleurs c'est totalement éronné, et dans tout les cas, ce qu'il faut avant tout c'est savoir sécurisé ses scripts.

je fasse un gros script PHP qui fasse un genre de proxy

Absoluement pas. Un proxy c'est entre deux machines distantes. La tu lis le fichier cible en local sur le disque dur et tu l'affiche. C'est ce que fais apache quand tu lui demandes un HTML par exemple, sauf que la tu passe par PHP, ce qui ne change vraiment rien, à condition bien sur d'implémenter un cache performant dans ton code PHP reproduisant les entêtes apache. ( E-tags, etc... )

L'idée de mettre les données dans un fichier directement est très pertinente, et peut offrir des performances bien supérieure à Mysql. Maintenant que tu puisses lire en clair le fichier, signifie qu'il n'y a pas de sérialisation PHP avant l'écriture dans le fichier, donc les donnés sont cash, dans le fichier. Se pose un problème de délimitation.

Si tu as un fichier méta-informations:
auteur
date
nombredeposts
autre1
autre2

et que l'utilisateur rentre dans le nom un "\n", il peut mettre un sacré bins dans l'application

Dans ton cas, le choix de l'utilisation des fichiers me semble obsolète.
Tu demandes à ton script de lire des tonnes de fichiers. Imaginons qu'il y est 50 messages sur un topic. Le script doit lire 100 fichiers pour le topic en lui même et parcourir 50 répertoires, qui plus est si le script affiche les infos des membres qui ont un profil dans un fichiers spéraré on va vite arrivé à un nombre très importants d'accès disques par requête !

L'idée du cache est donc bonne, et le PHP suffira emplement pour ça.
Par contre ça aura un inconvénient avec un forum comme le tient, mettre en cache oui mais pendant combien de temps ? Si un utilisateur X a sa page mise en cache 1 Heure et qu'un Y poste entre temps, ben il ne le verra pas. Alors oui tu peux toujours recalculer par requête les dates dernières modifications de fichiers mais c'est toujours pareil: pas économique du tout !

Bref tu es quand même très limité: si un utilisateur poste une réponse, ben il faut bien que ça soit effectif dans le listing des topics par exemple ! Impossible donc de mettre en cache, à mois de faire un truc bancal qui n'affiche que le titre et encore !

Si quelqu'un rajoute un topic, ben faut calculer sans arrêt le nombre de topic.

Dernière modification par yopploup (Le 21/10/2009, à 20:36)

Elzen · Le 21/10/2009, à 21:40

yopploup a écrit :

Puisque personne ne le fait, c'est qu'il y a une raison

En effet : 99% des gens sur cette planète (à mon grand regret) n'ont strictement rien à foutre d'avoir les trois quarts de leurs données enregistrées sur les serveurs Google.

yopploup a écrit :

Un problème pas vraiment non ... il y a 6 types de fichiers maximum à tout cassé dans ton site... que j'ai sous les yeux !

À tout casser. Et je n'ai pas parlé de types de fichier, j'ai parlé de fichiers tout court. En quoi le fait qu'il n'y ait qu'un nombre limité de types différents fait qu'il ne faudrait pas, en suivant ce que tu dis, rajouter une en-tête PHP sur chaque ? Parce que c'est ça, mon problème, je rappelle : faire appeler un script avant d'envoyer un fichier, quel que soit son type, sans que ce script n'ait eu besoin d'être intégré au fichier.

yopploup a écrit :

C'est faux, il ne s'agit pas de mettre les données hors de la racine web.
D'ailleurs c'est totalement éronné, et dans tout les cas, ce qu'il faut avant tout c'est savoir sécurisé ses scripts.

sécuriser. Et si l'on veut (ce que je ne veux pas, d'ailleurs, mais c'est l'hypothèse dont je parlais) que des fichiers ne soient pas accessible, il faut les placer autre part sur le disque (ce qui ne pose aucun problème si on y accède via un script PHP, qui peut accéder aux fichiers normalement), ou bien utiliser une solution alternative (genre .htaccess) pour bloquer l'accès à ces fichiers. La première étant la plus efficace.

yopploup a écrit :

Absoluement pas. Un proxy c'est entre deux machines distantes.

Un proxy est quelque chose qui sert à aller récupérer quelque chose pour toi. On l'utilise entre autres comme intermédiaire pour accéder aux sites Web, mais pas seulement. Notamment, il existe une classe "Proxy" en Java qui peut servir d'intermédiaire à l'utilisation d'autres classes.

yopploup a écrit :

et que l'utilisateur rentre dans le nom un "\n", il peut mettre un sacré bins dans l'application

Je sais échaper les chaînes de caractères, merci.

yopploup a écrit :

Tu demandes à ton script de lire des tonnes de fichiers. Imaginons qu'il y est 50 messages sur un topic. Le script doit lire 100 fichiers pour le topic en lui même et parcourir 50 répertoires, qui plus est si le script affiche les infos des membres qui ont un profil dans un fichiers spéraré on va vite arrivé à un nombre très importants d'accès disques par requête !

Ce qui est précisément la raison pour laquelle je suis en train de reprendre le code.

yopploup a écrit :

L'idée du cache est donc bonne, et le PHP suffira emplement pour ça.

Je fais générer des fichiers HTML. Ça permet d'accéder aux données y compris hors-ligne.

yopploup a écrit :

Dans ton cas, le choix de l'utilisation des fichiers me semble obsolète.

D'ailleurs, tout ça me rappelle qu'au départ, j'avais demandé de l'aide, pas du Troll. J'ai toute une préconception assez élaborée, que je n'ai pas l'intention d'envoyer valser juste parce que ça ne te plaît pas. Alors étant donné que j'ai posté pour demander des suggestions à propos d'un simple petit soucis technique (à savoir, je rappelle, comment faire en sorte qu'un script soit appelé par Apache avant d'accéder au fichier demandé), est-ce que tu pourrais soit y répondre, soit me laisser développer mon truc tranquillement et garder tes critiques pour quand ce sera d'actualité ?

Dernière modification par ArkSeth (Le 21/10/2009, à 23:06)

rmy · Le 22/10/2009, à 01:26

Je retourne ton problème dans tout les sens et je crois que j'aurais fait un mix de la solution cache/bdd.

Pour moi, il n'y a pas d'intérêt à stocker toutes les valeurs du type "flag-fichier" et fichier d'infos hors bdd, puisque tu n'y accèderait que ponctuellement pour vérifier l'obsolescence (ouahhh c'est bô comme mot) d'une page ou pour la regénérer avec des infos "stables" (par opposition à variables) ex : auteur, date du post, modifié ou non, sujet général, catégorie etc....

Je comprends bien par contre le côté pratique et rentable du fichier texte pour les posts, qui sont par essence modifiables, et l'idée que la structure corresponde au web...

Bref, voilà la solution que je proposerais à ton problème. Il y en a d'autres, pas meilleures ou plus mauvaises, mais à choisir pour ce qui te conviendrait le mieux :

à la racine script php et divers (fonctions à mettre en include pour vérif la session etc...) q ui traite toute la partie dynamique, login, vérif de session, variables de session et le recoupement avec la BDD.

Ensuite, deux arborescences de dossier identiques :
l'une /html/etc...
l'autre /txt/etc...

dans le /text/etc... tu stocke tous tes fichiers lors de la création ou l'édition.
dans le /html/etc... tu stocke tout le "cache" html des pages déjà générées en prenant en compte la partie variable ponctionnée dans /text/etc et les infos stables en BDD

Une bdd donc, avec des tables d'enregistrements de valeurs (login / pass / dernier édit / pseudo auteur / nombre de messages / couleur des cheveux etc...), et des tables structurelles qui gèrent la concordance entre les noms des fichiers et leur auteur par exemple...

Enfin, je persiste à penser que la génération des pages html doit se faire lors de la modification plutôt que lors de l'appel. Ainsi, la page html est modifiée pour tous les membres en lignes simultanément, une page de "cache" sert à tout le monde. C'est là que ça prend son intérêt, parce que mettre en cache une page pour l'utilisateur lui même... c'est utiliser plus de ressources que l'on en gagne...

Il te reste enfin à te faire un petit script d'administration, c'est plus élégant d'accéder à des pages persos quand tu te logues qui te permettent de créer directement tes fichiers en ligne (et/ou de les importer si tu rédiges pendant les transports)... puis d'actualiser le site à demande. La BDD te permettrait alors aisément de gérer un "ordre d'affichage" voir un statut (affiché / obsolète=grisé / non affiché etc...) pour tes textes perso...

Voilà... je m'en retourne à mes installations sportives et à la gestion des créneaux disponibles.

PS : si tu as une idée pour un script de gestion de tournois complet... Je ferai un post un jour

Elzen · Le 22/10/2009, à 09:45

Ta solution est effectivement très élégante, mais elle ne correspond pas vraiment à ce que je recherche (je veux que le site soit entièrement administrable avec des fichiers, afin qu'une simple copie des fichiers sur un ordinateur non-serveur puisse permettre de tout réutiliser sans problème et que l'administration puisse s'y faire). Donc merci beaucoup, mais le problème reste posé.

rmy a écrit :

Enfin, je persiste à penser que la génération des pages html doit se faire lors de la modification plutôt que lors de l'appel. Ainsi, la page html est modifiée pour tous les membres en lignes simultanément, une page de "cache" sert à tout le monde. C'est là que ça prend son intérêt, parce que mettre en cache une page pour l'utilisateur lui même... c'est utiliser plus de ressources que l'on en gagne...

En fait, l'idée de base était de retarder la création du fichier résultat jusqu'à ce que l'on en ait besoin (inutile de le faire générer immédiatement si personne ne va le lire avant le mois d'après). Mais ceci dit, finalement, je pense que je vais suivre ton conseil et inverser : le fichier sera généré dès le changement. Pour la gestion hors-ligne, ce sera sûrement plus pratique.

rmy a écrit :

PS : si tu as une idée pour un script de gestion de tournois complet... Je ferai un post un jour

Tournoi de quoi ? Hésite pas à donner plus d'infos

rmy · Le 22/10/2009, à 12:50

ArkSeth a écrit :

Tournoi de quoi ? Hésite pas à donner plus d'infos

Tournois, tout types, c'est là la difficulté... Je bute sur les diverses théories de représentation intervallaire d'un arbre hiérarchique. Il me faut pouvoir gérer des tournois de poules à n équipes ou n individus, avec match simple, A/R, plusieurs sets, etc... et aussi des tournois type tennis à élimination directe. Des tournois mixtes qui permettent les deux. La gestion de la constitution des équipes. La possibilité d'ajouter une équipe en cours de route. L'aide à la construction du classement avec des règles pré-définies. La possibilité d'enregistrer pour chaque match/rencontre des évènements supplémentaires qui peuvent être utiles par la suite (cartons, expulsions, fair-play, formation arbitrage etc etc...)

Bref, un tout-en-un du tournoi, qui traîne dans un coin de ma tête pour un jour.

Elzen · Le 22/10/2009, à 13:21

Ah, oui, en effet, ça promet ^^ Ben écoute, quand tu te mettras à bosser dessus, préviens

Bon, je passe le sujet en résolu, puisque je viens d'avoir la réponse à la question d'origine, à savoir comment faire pour faire lancer un script par Apache avant d'accéder à un fichier. Link Mauve m'a signalé une simple ligne de conf qui permet ça :

Action mimitype script

en remplaçant mimitype par le type de fichiers concernés (image/png, text/html, etc...) et script par l'arborescence du script (vue depuis le web). Dans mon cas, il faut que je répète la ligne pour chaque type de fichiers, mais ce n'est pas trop lourd.
Ceci fait appel au module action, qu'il faut donc avoir activé préalablement (en console, en root : a2enmod actions), et l'exécution du script remplace l'accès au fichier, donc puisqu'il s'agit d'un script PHP, les dernières lignes sont

header("Content-Type: ".$_SERVER["REDIRECT_HANDLER"]);
require_once($_SERVER["PATH_TRANSLATED"]);

pour qu'il termine quand même par renvoyer le fichier (avec le bon type mime).
Le script n'est pas appelé en cas d'erreur 404 (ou autres), mais si je suis la suggestion de rmy, la génération de fichiers se fera lors de la modification et pas à l'affichage, donc je n'en ai pas besoin.

Je viens de faire quelques tests, et je devrais pouvoir réussir à développer ce que je veux avec ça. Je vous tiens au courant de l'évolution

Dernière modification par ArkSeth (Le 22/10/2009, à 13:21)

yopploup · Le 22/10/2009, à 14:05

j'avais demandé de l'aide, pas du Troll

Ce n'est pas parce que tu n'as pas les connaissances nécessaires que tu dois croire que je t'insultes !

Je prends du temps pour rédiger ces topics, t'aider, te conseiller, proposer des solutions.
Tu ne lit qu'en travers ce que je te dis et n'essaye pas d'approfondir, c'est assez désolant car je te tends la solution depuis mon premier post...

Maintenant on peut se la jouer " on poste en s'aggressant ".

Et je n'ai pas parlé de types de fichier, j'ai parlé de fichiers tout court. En quoi le fait qu'il n'y ait qu'un nombre limité de types différents fait qu'il ne faudrait pas, en suivant ce que tu dis, rajouter une en-tête PHP sur chaque ? Parce que c'est ça, mon problème, je rappelle : faire appeler un script avant d'envoyer un fichier, quel que soit son type, sans que ce script n'ait eu besoin d'être intégré au fichier.

Exemple:
Un internaute execute, GET /images/image1.jpg HTTP/1.1 comme il aurait pu executer:
GET /images/image2.jpg HTTP/1.1
GET /images/image4.jpg HTTP/1.1
GET /js/js1.js HTTP/1.1
etc...

Un script PHP, récupère le nom de l'image, ici: image1.jpg ( Url rewriting dans notre cas )
Le script PHP effectue les tests d'identification de session précédemment créée.
La session est valide, donc c'est un utilisateur physique, le script PHP génère, grace à l'extention prise dans le nom de fichier, le type MIME associé. Il envoie le tout, les entêtes surmonté du fichier lui même, lu, depuis son chemin physique, exemple: "/home/site1/www/datas/imgs/image1.jpg"

Dans cet exemple, il te manque l'implémentation du cache, mais d'après ta propre description, ça répond parfaitement à tes attentes. Cette solution propre, ne requiert d'ailleurs pas une bidouille APACHE.
Le script PHP est "bien appelé" avant l'envoie du fichier lui même, ce qui te permet de faire tes contrôles.
Apache n'a rien à voir la dedans.

Après si tu continues à être de mauvaise fois, je ne peux plus rien pour toi.

En effet : 99% des gens sur cette planète (à mon grand regret) n'ont strictement rien à foutre d'avoir les trois quarts de leurs données enregistrées sur les serveurs Google.

Ce que je voulais dire c'est que la page d'accueil n'est pas totalement optimisé, et qu'il est possible de faire quelque chose de plus transparent pour l'utilisateur sans compromettre les données du site. Exemple: passer par un javascript dynamique.

Je sais échaper les chaînes de caractères, merci.

Facile à dire maintenant que je te l'ai dit.
En tout cas je doute que tu penses à tout, au niveau sécurité, vu comment tu galères déja pour une babiole en PHP !

L'idée du cache est donc bonne, et le PHP suffira emplement pour ça.

Je fais générer des fichiers HTML. Ça permet d'accéder aux données y compris hors-ligne.

Comme si on ne le savait pas.

Dernière modification par yopploup (Le 22/10/2009, à 14:15)

Elzen · Le 22/10/2009, à 14:55

yopploup a écrit :

Ce n'est pas parce que tu n'as pas les connaissances nécessaires que tu dois croire que je t'insultes !

Je te retourne le compliment : ce n'est pas parce que tu as des idées différentes des miennes ou que tu ne comprends pas ce que j'essaye d'expliquer qu'il faut croire que je n'ai pas les connaissances requises. Tu m'insultes en réagissant ainsi.

yopploup a écrit :

Je prends du temps pour rédiger ces topics, t'aider, te conseiller, proposer des solutions.

Non : tu prends ton temps pour me dire comment tu aurais fait toi en ignorant royalement le fait que ça ne correspond absolument pas à ma demande.

yopploup a écrit :

c'est assez désolant car je te tends la solution depuis mon premier post...

Ah ? Curieux. On ne doit pas parler la même langue, parce que tout ce que je vois dans ton premier post, ce sont les pistes que tu connais pour esquiver les robots, ce qui ne risque pas d'être "la solution", puisque ce n'est pas du tout ce que je demandais.

yopploup a écrit :

Maintenant on peut se la jouer " on poste en s'aggressant ".

Je suppose qu'on peut, en effet, puisque c'est ce que tu as commencé à faire il y a quelques temps déjà.

yopploup a écrit :

Cette solution propre, ne requiert d'ailleurs pas une bidouille APACHE.

Apache. Et pas de bidouille, excepté bien sûr l'URL Rewriting, qui est la plus grosse bidouille jamais inventée en matière d'accès aux sites Web. Désolé si on a pas la même notion de la propreté, mais ajouter une ligne dans le fichier de configuration afin d'effectuer un traitement préalable me paraît largement plus propre que de réécrire totalement chaque requète.

yopploup a écrit :

Après si tu continues à être de mauvaise fois, je ne peux plus rien pour toi.

Même réponse à ton attention.

yopploup a écrit :

Exemple: passer par un javascript dynamique.

Effectivement, je vois que tu penses professionnel : tu penses comme les professionnels qui codent leur site pour IE parce que c'est le plus utilisé, en se foutant royalement des standards "parce que ça ne concerne pas grand monde".
L'une des règles de bases en matière d'accessibilité est de réserver le JavaScript uniquement à des parties non-essentielles du site, étant donné que certains utilisateurs n'ont pas JavaScript activé. Coder le panneau d'accueil en JavaScript signifierait soit que le site serait innaccessible à ces personnes, soit que le panneau d'accueil ne s'afficherait que chez les autres et ne servirait donc strictement à rien.

yopploup a écrit :

Facile à dire maintenant que je te l'ai dit.

Parce que tu crois réellement que je t'ai attendu pour y penser ? Je ne sais pas comment tu as appris à coder, mais chez moi, gérer l'échappement des caractères a toujours été la première préoccupation sur les cas de lecture/écriture de ce genre.

yopploup a écrit :

En tout cas je doute que tu penses à tout, au niveau sécurité, vu comment tu galères déja pour une babiole en PHP !

Doute autant que tu veux si ça peut te faire plaisir. Au fait, juste comme ça : je ne "galère" pas pour "une babiole en PHP", je demande un renseignement sur la configuration d'Apache, mais je suppose que ça n'a pas d'importance.

yopploup a écrit :

Comme si on ne le savait pas.

Manifestement, tu ne savais pas, puisque tu t'obstines à me proposer des réponses s'axant uniquement sur la nécessité de passer par un serveur, alors que j'ai précisé plusieurs fois que le but de la manœuvre était de laisser l'ensemble accessible sans. Lequel de nous deux ne lis les posts qu'en diagonal, au fait ?

Dernière modification par ArkSeth (Le 22/10/2009, à 14:58)

Grünt · Le 22/10/2009, à 15:17

ArkSeth a écrit :

yopploup a écrit :
Si j'ai bien compris, tu essaye de te protéger des robots.
Le problème n'est pas là : ça, j'y arrive déjà très bien (et au passage, ce que je veux, ce n'est pas seulement ne pas être indexé, c'est que mes données ne se retrouvent pas dans les ordinateurs de Google et consorts, parce que c'est mes données à moi et pas les leurs. Je suis peut-être un peu parano sur les bords, mais avec un robots.txt, on a aucune assurance qu'ils ne mémorisent pas tout chez eux, même s'ils ne les affichent pas dans les résultats de recherche.

Si tu lisais tes logs apache en mettant un robots.txt tu verrais que, lorsque le GoogleBot fait un "GET /robots.txt" et qu'il voit qu'il n'est pas le bienvenu, il ne GET plus rien d'autre et laisse tomber ton site.

Elzen · Le 22/10/2009, à 16:48

Certes.

Sauf que comme je l'ai dit, je n'ai pas envie d'interdire totalement la récupération par Google (qui est d'ailleurs loin d'être le seul robot indexeur de la toile. Les as-tu vérifié tous ?) des données de mon site. Au contraire, il y a certaines pages que je suis très content de voir indexées et référencées. Celle-là, par exemple. Et comme ces pages non-protégés se situent un peu partout sur le site (donc pas désignables simplement par une unique regexp) et qu'en bon informaticien, je suis fondamentalement feignant et assez compartimenteur, je préfère amplement gérer ça au cas par cas (un petit booléen dans les méta-informations de la page) plutôt que de réécrire sans arrêt un même fichier qui référencerait d'un seul coup tout ce qui est accessible et tout ce qui ne l'est pas sur le site.

Dernière modification par ArkSeth (Le 22/10/2009, à 16:50)

yopploup · Le 22/10/2009, à 18:38

ce n'est pas parce que tu as des idées différentes des miennes

C'est faux. Il s'agit de ma propre expérience. L'idée de l'utilisation des fichiers n'est pas nouvelle. J'ai évoquée quelques pistes au passage qui seront utile pour d'autres personnes qui navigueront sur le topic. C'est bien gentil de penser d'abord à son propre problème, mais rien ne m'empêche d'élargir un peu le sujet et la question pour les autres.

pas de bidouille, excepté bien sûr l'URL Rewriting, qui est la plus grosse bidouille jamais inventée

Pas vraiment sympa de critiquer de la sorte les développeurs de ce module libre et gratuit.
Permet moi de t'envoyer lire son code source. Tu constateras que c'est au contraire très bien pensé. Ce n'est pas pour rien que des sites à échelle mondiale l'utilise, tel que YouTube.

D'ailleurs, ce n'est pas pour rien, que les forums libre et commerciaux ne sont pas créé avec des milliers de fichiers comme ton application. Après quand on a aucune notion en système...

En plus rien ne t'oblige de l'utiliser avec un appel à du PHP direct, ça l'aurait fait parfaitement.

Une autre chose sur ton site:
La requête: index.php?gen=style nous renvoie ... attention ...
un: Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Très très bien pensé ! A chaque requête, la personne retélécharge le fichier CSS !
Se permettre de donner des conseils d'optimisations après ça est absolument hilarant.

tu penses comme les professionnels qui codent leur site pour IE parce que c'est le plus utilisé, en se foutant royalement des standards "parce que ça ne concerne pas grand monde".

Ahhh j'oubliais: dans le même genre: export.php?user=XXXXXX&file=XXXXXXX
Qui renvoie à chaque requête l'image au complet !

Ne parlons pas de ce lien:
reply.php?gen=script&posts=Coucou qui passe en paramètre un post qui n'est pas utilisé dans le script ! Et oui ça c'est du codage

Sans compter les javascripts vulgairement repompés sans mention des auteurs ne serait-ce que dans le source, pour des applications dont la modification n'est pas autorisée.
( C'est pourtant la mointe des choses ... )

"Message n°0" ...

Je ne lirais pas le code source des PHP, je pourrais y écrire un roman d'erreurs en 3 tomes.

est de réserver le JavaScript uniquement à des parties non-essentielles du site

Tu peux parler, avec une vieille page de connexion dès l'acceuil qui rempli la page ... ton site est effectivement très accessible Surtout que le site n'est valide qu'en transitionnal ...

Le javascript était ici une piste simple, mais je ne proposerais plus de pistes, puisque tu es restreint d'esprit et pense détenir la vérité.

Je ne sais pas comment tu as appris à coder

Effectivement, on a pas appris à coder au même endroit ( dieu soit loué ).

Je suppose que tu va t'empresser de modifier tout ça et de dire non non tout fonctionne mais à vrai dire je m'en fiche: les gens censés comprendront.

Pour moi la discution est close, ce qui ne m'empêchera pas de continuer à rire doucement avec tes posts et ton pseudo site.

Dernière modification par yopploup (Le 22/10/2009, à 19:00)

rmy · Le 22/10/2009, à 20:30

yopploup, tu es certainement un demi-dieu en administration serveur et réseaux et en scripting php, mais en communication, tu t'approches du nerd boutonneux.

Il n'y a qu'une seule chose à comprendre dans les posts précédents : ta proposition est certes valide mais ne convient pas pour de bonnes raisons à la personne qui cherche une solution.

En insistant pour vouloir absolument avoir raison et imposer ton mode de pensée, tu ne fais que polluer la discussion d'autres utilisateurs moins forts (comme moi ?) qui cherchent à trouver une proposition adaptée à la demande. Ce que je n'ai pas réussi à faire, mais je l'ai entendu et j'ai cherché autre chose.

Si tu viens poster juste pour étaler ta science et que tu es incapable d'entendre les requêtes des gens qui t'entourent, tu ne sera bientôt plus qu'une erreur 404. J'espère que ton métier n'est pas de faire des sites web pour des clients... car sinon soit ils n'ont aucune vison de ce qu'ils veulent et tu dois leur convenir par ton assurance, soit ils doivent s'écraser sous ton autoritarisme vindicatif. Non, Bravo.

Des gens compétents, il en faut plein pour alimenter un forum et apporter des solutions.
Des gens pédants, c'est déjà dur à supporter de les voir polluer les pages.
La troisième catégorie ferait mieux de s'abstenir.

Dernière modification par rmy (Le 22/10/2009, à 20:31)

Grünt · Le 22/10/2009, à 20:34

Tiens, il vaut mieux être commercial que développeur pour faire du libre, maintenant? Mauvaise nouvelle

rmy · Le 22/10/2009, à 20:41

"faire du libre", ça s'arrête au concept logiciel pour toi ? Ou chacun est libre de faire comme il veut ce qu'il veut ?

Dernière modification par rmy (Le 22/10/2009, à 20:41)

Grünt · Le 22/10/2009, à 20:46

rmy a écrit :

"faire du libre", ça s'arrête au concept logiciel pour toi ? Ou chacun est libre de faire comme il veut ce qu'il veut ?

Pour moi ça s'arrête à deux choses:
- il faut que ça fonctionne bien,
- il faut que ça soit libre.

De ce topic j'aurai appris une chose: si j'ai besoin d'un coup de main en PHP c'est à yopploup que je demande.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 21/10/2009, à 12:41

[Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#2 Le 21/10/2009, à 13:13

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#3 Le 21/10/2009, à 14:12

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#4 Le 21/10/2009, à 14:21

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#5 Le 21/10/2009, à 14:23

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#6 Le 21/10/2009, à 17:06

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#7 Le 21/10/2009, à 18:39

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#8 Le 21/10/2009, à 18:46

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#9 Le 21/10/2009, à 19:16

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#10 Le 21/10/2009, à 19:44

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#11 Le 21/10/2009, à 20:29

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#12 Le 21/10/2009, à 21:40

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#13 Le 22/10/2009, à 01:26

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#14 Le 22/10/2009, à 09:45

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#15 Le 22/10/2009, à 12:50

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#16 Le 22/10/2009, à 13:21

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#17 Le 22/10/2009, à 14:05

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#18 Le 22/10/2009, à 14:55

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#19 Le 22/10/2009, à 15:17

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#20 Le 22/10/2009, à 16:48

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#21 Le 22/10/2009, à 18:38

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#22 Le 22/10/2009, à 20:30

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#23 Le 22/10/2009, à 20:34

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#24 Le 22/10/2009, à 20:41

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

#25 Le 22/10/2009, à 20:46

Re : [Résolu] Lancement d'un script par apache avant l'envoi d'un fichier.

Pied de page des forums