PHP
Le site GForceSoftware nouveau est arrivé.
Il est hébergé sur le serveur d’Ohm Force dont j’ai la charge ; c’était une expérience intéressante, car je devait mixer une application à base de Servlets avec une application PHP, derrière le même domaine.
En frontal, il y a nginx, le serveur http russe léger et qui fonce.
Pendant 24 heures, il y avait un trou de sécurité flagrant, qui permettait de récupérer le code source des scripts php, à cause de svn. (je me suis tapé sur la tête quand je m’en suis rendu compte. Heureusement en analysant les logs, personne n’a eu l’idée de l’exploiter).
SVN
Le déploiement sur la production, c’est un checkout des scripts. C’est à dire que tous les répertoires ont un répertoire .svn qui contient les métadonnées sur les fichiers du répertoires ainsi qu’un cache contenant les fichiers originaux tels qu’ils sont stockés sur le repository svn.
Les fichiers originaux sont identifiés par une extension svn-base.
La faille
Or la configuration du serveur est d’envoyer le contenu tel quel pour une extension inconnue.
Du coup, on pouvait récupérer le code de la page d’index avec ce lien :
http://www.gforcesoftware.com/.svn/text-base/index.php.svn-base
Pas glop.
La correction
Donc pensez bien à ajouter la configuration suivante dans votre serveur web (ici pour nginx) :
location ~ .svn/ {
deny all;
}
La conclusion
C’est un des trucs qui me plaît le moins avec PHP, le fait que l’arborescence détermine l’URL, je préfère un MVC un peu plus abstrait comme avec les servlets ou avec Rails. On a beaucoup plus de souplesse, sans s’encombrer de rewrite rules trop complexes.
Vu que pour le MVC, toutes les URLs sont masqués derrière le contrôleur l’utilisateur ne sait même pas quel est l’arborescence système.
Sur le site Ohm Force, les JSP elles-même sont cachés dans le répertoire WEB-INF dont le contenu n’est pas publié.
Bonjour,
il est fortement déconseillé de faire un checkout sur un serveur de production. Un export évite d'avoir les dossiers de travail .svn.
Sinon PHP permet parfaitement d'avoir une arborescence abstraire, comme je l'ai utilisé ici http://placedusport2.com/nimes2007/photo.php/FR/12/2980/podiums-adultes
Et une seule règle de rewriting m'aurait permis de retirer le photo.php mais je n'en ai pas eu le temps à l'époque. L'avantage de rails et consorts est qu'ils le font par défaut, sans qu'on ait à se poser la question.
Cordialement Cédric
C'est vrai ... mais j'aime beaucoup svn switch sur des tags pour le passage en production, on gagne du temps sur les transferts :)
Par rapport à la conclusion : pour faire du MVC en PHP il y a plusieurs frameworks prévus juste pour combler cette lacune.
Personnellement je recommande Code Igniter qui a le mérite de s'apprendre en moins d'une matinée (par rapport à CakePHP et ses amis...) et d'être léger!
En regardant les deux vidéos du site puis en survolant la doc (pour ceux qui aiment lire) n'importe quel programmeur PHP digne de ce nom peut immédiatement faire du MVC sans s'arracher les cheveux ;-)
Et si on ajoute jQuery pour le javascript on obtient une combinaison parfaitement "Web 2.0-compliant" pour coder des sites "next-gen" en vraiment peu de temps!