Wikini

DiscussionsRendreLesHandlersModulaire

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-3-81-23-50.compute-1.amazonaws.com

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 :
--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 :
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'])) {
}
?>

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 :
-- 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


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")
{
}
?>

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")))
{
}
?>

--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

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 :
-- 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]


Corrélats



PatrickPaulASuivre PageSuivieParGarfieldFr CharlesNepoteASuivreEnPriorite


Commentaires [Cacher commentaires/formulaire]