Idée : rendre les handlers modulaires
Cela permet d'écrire des handlers et de les ajouter à
WikiNi sans avoir à modifier le fichier wakka.php.
Les handlers sont disponibles juste en les mettant dans le répertoire /handlers/page/. La modification est assez simple :
- Remplacer le switch ... case ... de la méthode wiki::Run() par print($this->Method($this->method));
- Modifier tous les handlers pour que la première chose qu'ils fassent soit un echo $this->Header(); et la dernière un echo $this->Footer();
- Cas particulier pour xml : ajouter header("Content-type: text/xml"); au debut de xml.php, ne pas appeler Header() et Footer()
- Cas particulier pour raw : ne pas appeler Header() et Footer()
--
GarfieldFr
Cela signifie qu'il faut appeler les header et footer dans acls.php, addcomment.php, claim.php, diff.php, edit.php, referrer.php, etc.
Ce principe de modularisation va permettre de développer plus facilement des choses dont on a même pas encore idée :
- sortie PDF,
- fichier foaf pour chaque utilisateur,
- version des pages pour les lecteurs mobiles,
- etc.
Après, libre à nous de proposer ces handlers en option ou directement avec la distribution de base de
WikiNi.
(Et c'est une modification qui ne coûte ni performance ni octets supplémentaires (ou si peu).
--
CharlesNepote
Appel des handlers
Ce qui me semble important techniquement : les handlers ne doivent pas pouvoir être appellés directement, par exemple
http://www.wikini.net/handlers/page/show.php plante et c'est bien : on a ainsi une plus grande maîtrise des arguments qui lui sont passés. Toujours plein de bonnes idées
GarfieldFr ! --
DavidDelon
Pour le controle d'accès direct, on peut écrire ce code au début des handlers :
<?php
if (!eregi("wakka.php", $_SERVER['PHP_SELF'])) {
- die ("accès direct interdit");
}
?>
Un appel direct au handlers plante et affiche un beau message !! Je le rajoute, ca sert peut être à rien mais dans le doute... En plus ca affiche un message un peu plus discret que le message d'erreur php. --
GarfieldFr
Sur le fait d'avoir rendu les handlers modulaires, c'est super ! :)
Sur le fait de les protéger avec
eregi("wakka.php", $_SERVER['PHP_SELF']), c'est fonctionnel avec ou sans ré-écriture d'URL, c'est bien vu ! :) Je suggère tout de même de remplacer par
preg_match("/^[^?]*\/wakka.php$/", $_SERVER['PHP_SELF']) pour être plus strict sur la vérification, sinon on pourrait appeler le script via
handlers/page/acls.php?var=/wakka.php !
--
ProgFou
Oui. Ton expression rationnelle me semble mieux protéger l'appel à un script hors wakka.php. L'as-tu testée ? Avec et sans réécriture ?
N'est-elle pas encore cependant incomplète ? Ne peut-on en effet écrire :
- handlers/page/acls.php#/wakka.php
- ou utiliser d'autres caractères réservés définis dans la RFC:1738 (interwiki) (chapitre 2.2).
--
CharlesNepote
Je l'ai testée dans les deux cas : c'est fonctionnel. Mon site utilise la ré-écriture d'URL et il est donc très simple de tester : il suffit de faire une première requête sur
.../PagePrincipale puis une seconde sur
.../wakka.php?wiki=PagePrincipale et le test est fait ! Ceci car je ne fixe pas le paramètre de ré-écriture d'URL en dur dans le fichier de configuration, mais je le laisse se calculer automatiquement avec la correction que j'ai proposé dans les
RapportsDeBogues. ;-)
Je n'avais pas pensé aux autres cas que tu proposes, qui posent effectivement problème !! Je vais fouiner un peu du coté de PHP pour voir s'il n'y aurait pas moyen de déterminer dans le script lui-même s'il est inclu d'autre part ...
--
ProgFou
- Le fait de passer wakka.php comme argument de l'URL ne fait pas passer le test, en effet, $_SERVER['PHP_SELF'] ne contient que l'URL du script sans les paramètres, cela implique donc que handlers/page/acls.php?var=/wakka.php ne passera pas puisque wakka.php est alors un paramètre. Par contre, il faut peut être réécrire le test pour régler des problèmes de réécriture d'URL. --GarfieldFr
- Exact, je viens de remarquer cela aussi. Et c'est aussi ce qui me sauve pour l'auto-détection du mode de ré-écriture d'URL ! -- ProgFou
Cela veut dire qu'il faut réévaluer vos codes respectifs ? Si vous trouvez une solution adéquate, n'oubliez pas de documenter la page
EcrireUnHandler que je viens de rédiger. --
CharlesNepote
Essayons de lister les cas de problèmes potentiels :
Et ce qui doit seulement être autorisé : c'est un appel
via wakka.php. Ne suffit-il donc pas d'effectuer un test sur la valeur d'une constante définie dans wakka.php, par exemple WIKINI_VERSION ? Ce qui nous donnerai donc :
<?php
if (!defined("WIKINI_VERSION")
{
- die ("accès direct interdit");
}
?>
Qu'en pensez-vous ?
(Je n'ai toujours pas eu d'avis sur la question. Je pense pourtant que c'est la bonne solution. Pourrais-je intégrer au CVS (quand celui-ci sera rétabli) ?)
--
CharlesNepote
Ok pour moi --
DavidDelon
On peut mettre les 2 filtres comme cela on est sur que ca passera pas ....
<?php
if ((!eregi("wakka.php", $_SERVER['PHP_SELF']))||(!defined("WIKINI_VERSION")))
{
- die ("accès direct interdit");
}
?>
--
GarfieldFr
Le coup de la constante me parait pas mal.
Le seul moyen de le contourner serait une faille xss qui de toutes façons serait exploitable autrement : si quelqu'un trouve un moyen de faire exécuter le php de son choix (via un formulaire, ou un upload ou autre) il pourra forcer à définir la constante WIKINI_VERSION et appeler directement les handlers. Mais dans ce cas, il pourra faire beaucoup plus grave et ce sera donc le cadet de nos soucis ;-)
Donc on pourrait éviter d'alourdir le code avec une regexp en plus à chaque touche.
--
PiiF
Oui, je ne vois pas l'intérêt d'ajouter une regexp...
--
CharlesNepote
- Je vote aussi pour faire sans la regexp, c'est à dire uniquement avec la constante WIKINI_VERSION. -- ProgFou
- OK, pas de problème alors, juste la version avec la constante WIKINI_VERSION --GarfieldFr
Si je puis me permettre... C'est complètement débile d'écrire un bout de code pour "interdire l'accès direct" alors que la solution propre est manifestement d'écrire tout le code dans des fonctions ou des méthodes.
Exemple : le fichier actions/spip.php contient une fonction actions_spip($...) ou une classe Actions_Spip qui fait tout le boulot.
-- Antoine.
En effet, mais comme il n'est pas question pour l'instant de réécrire
WikiNi entièrement, cette solution est pratique (même si d'après toi
débile). --
GarfieldFr
Que reste-t-il à faire ?
Maintenant que nous avons pris la décision pour l'appel, il reste ces tous petits rien qui font un projet bien tenu :
- [OK] mettre à jour le CVS (chaque action...)
- J'y pense, le contrôle d'appel direct est valable en fait pour tous les fichiers wikini en dehors de /wakka.php... non ? -- CharlesNepote [Oui, ÀMHA. -- ProgFou]
- [partiellement] jardiner la page [ne peut-on pas même carément l'effacer ? -- CharlesNepote]
- Je pense à l'effacer mais je me pose la question de l'archivage des discussions... ne faut-il pas documenter aussi quelque part le fait que depuis 0.4.1 les handlers sont modulaires... -- CharlesNepote [Je propose que ce soit dans WikiNiChangelog, ou plutôt WikiNiNouveautes? (fichier NEWS dans une distrib) ou encore WikiNiChangelogResume?. Dans tous les cas, je serais d'avis de supprimer la discussion sur l'ancienne technique. -- ProgFou]
- [OK] documenter proprement l'histoire du .htaccess sur une autre page : cf. DocumentationSecuriserWikiNiAvecUnHtaccess
- [OK] documenter l'appel pour ceux qui souhaitent faire des actions : cf. EcrireUnHandler
--
CharlesNepote (alias "bibi qui s'y colle") [Je pense qu'il nous manque encore un truc niveau organisationnel : une page où on listerait les choses à faire dès que possible dans le CVS, où quelques décideurs (au moins deux par tâche ?) mettraient leurs noms pour indiquer leur accord, puis une personne mettrait son Nom pour indiquer qu'elle s'engage à le faire. Souvent je n'ose pas intervenir sur le CVS ne sachant pas si l'accord final est donné ou encore si quelqu'un d'autre s'en charge... --
ProgFou]
- arf arf ProgFou :-)) m'enfin vas-y! le principe de fonctionnement de cvs est le même que celui de wikini : il y a toujours possibilité de revenir à la version précédente (plus loin dans le temps d'ailleurs que wikini vu qu'il n'y a pas de purge sur un cvs). C'est d'ailleurs une force de cvs sur sccs quand les projets ne sont pas fortement coordonnés (i.e. pas de CdP? unique, sccs propose un lock si mes souvenirs sont bons). Donc GO vu qu'effectivement tout le monde semble d'accord au vu des discussions de cette page. Le "qui fait" serait idéalement à déterminer au début et donc affecté en fonction des dispos de chacun/intérêt/compréhension des modifs -- BenoitAudouard 20040719
Corrélats
PatrickPaulASuivre PageSuivieParGarfieldFr CharlesNepoteASuivreEnPriorite