quelques idées et une faille
le hollandais volant
Member
Bonjour,
Je suis l'actuel developpeur de Blogotext, un autre moteur de blog sans bases de données. (il fut crée puis délaissé par son auteur en 2006 avant que je le reprenne l'an dernier)…
Mais ce n'est pas pour ça discuter de ça que je viens en fait…
J'ai juste quelques idées pour Pluxml :
1) un cookie pour pré-remplir le formulaire de commentaires
J'ai constaté sur le blog d'un utilisateur de Pluxml que les champs pour poster les commentaires n'étaient jamais pré-remplis quand on revenait régulièrement sur le site.
Je sais pas trop si la question a été évoquée, ni ne connait le point de vue de la team sur la question (cookies...), toujours est-il que c'est dommage du point de vu d'un internaute de devoir taper à chaque fois mail, pseudo et site web
Pour remédier à cela il suffit juste ajouter quelques lignes de création des cookies en haut du fichier /index.php :
remplacer :
(Bien-sûr, pour les utilisateurs : adaptez ce code au fichiers thèmes que vous utilisez.)
Dans Blogotext, j'ajoute un test sur la présence ou non du cookie pour éviter une erreur PHP, mais là, je ne vois pas les erreurs s'afficher. J'imagine que Pluxml les masque ?
2) le fichier install.php
Quand j'ai installé Pluxml, j'ai vu ensuite dans le panneau d'administration un message me disant qu'il faille supprimer le fichier /install.php (pour des raisons de sécurité).
Ne serait-il pas plus simple d'un point de vu utilisateur de supprimer cette étape ?
Il suffirait de faire (dans le fichier /install.php) un test :
si pluxml a déjà été installé un fois (présence d'un compte admin) : on redirige sur la page d'acceuil
si pluxml n'a pas encore été installé : on procède à l'installation.
3) une possible faille
Une faille que à la quelle j'ai moi aussi eu droit dans Blogotext, c'est qu'un utilisateur connaissant le chemin d'un fichier source en XML peut accéder à son contenu, c'est à dire aussi à l'adresse IP de l'internaute (dans le cas d'un fichier d'un commentaire).
Bien sûr, j'ai vu la présence d'un fichier .htaccess censé bloquer cela, mais tous les hébergeurs ne prennent pas en compte ces fichiers. Il me semble que c'est le cas chez Free (l'un des plus gros hébergeurs Français).
Dans Blogotext, j'ai résolu le problème en ajoutant en haut de chaque fichier XML :
Cet ajout peut aussi rendre non-valide W3C le code source... Moi je n'y vois pas d'inconvénients pour Blogotext vu qu'il utilise sa propre syntaxe xml-like donc pas forcément conforme W3C non plus.
Encore une fois, je sais pas ce que vous en pensez : préférez-vous conserver un code source XML valide coute-que-coute au détriment de la sécurité de quelques utilisateurs, même minoritaires ? À vous de voir.
Autrement, ben, bravo pour Pluxml : je le trouve plutôt complet, surtout pour quelque chose d'aussi léger (400kio). C'est un logiciel agréable à utiliser et qui fait bien ce qu'on lui dit.
Y'a juste le mélange “html” et “php” dans le code qui me rebute un peu (Blogotext sépare complètement les deux), et qui demande des connaissances en PHP quand on veut créer un thème (en plus des connaissances HTML/CSS), mais sinon rien à dire personnellement
Je suis l'actuel developpeur de Blogotext, un autre moteur de blog sans bases de données. (il fut crée puis délaissé par son auteur en 2006 avant que je le reprenne l'an dernier)…
Mais ce n'est pas pour ça discuter de ça que je viens en fait…
J'ai juste quelques idées pour Pluxml :
1) un cookie pour pré-remplir le formulaire de commentaires
J'ai constaté sur le blog d'un utilisateur de Pluxml que les champs pour poster les commentaires n'étaient jamais pré-remplis quand on revenait régulièrement sur le site.
Je sais pas trop si la question a été évoquée, ni ne connait le point de vue de la team sur la question (cookies...), toujours est-il que c'est dommage du point de vu d'un internaute de devoir taper à chaque fois mail, pseudo et site web
Pour remédier à cela il suffit juste ajouter quelques lignes de création des cookies en haut du fichier /index.php :
# definition de cookies #
if (isset($_POST['name'])) { setcookie('name', htmlspecialchars($_POST['name']), time() + 365*24*3600, null, null, false, true); }
if (isset($_POST['mail'])) { setcookie('mail', htmlspecialchars($_POST['mail']), time() + 365*24*3600, null, null, false, true); }
if (isset($_POST['site'])) { setcookie('site', htmlspecialchars($_POST['site']), time() + 365*24*3600, null, null, false, true); }
remplacer :
comGet('name','');
comGet('name',htmlspecialchars($_COOKIE['name']));
(Bien-sûr, pour les utilisateurs : adaptez ce code au fichiers thèmes que vous utilisez.)
Dans Blogotext, j'ajoute un test sur la présence ou non du cookie pour éviter une erreur PHP, mais là, je ne vois pas les erreurs s'afficher. J'imagine que Pluxml les masque ?
2) le fichier install.php
Quand j'ai installé Pluxml, j'ai vu ensuite dans le panneau d'administration un message me disant qu'il faille supprimer le fichier /install.php (pour des raisons de sécurité).
Ne serait-il pas plus simple d'un point de vu utilisateur de supprimer cette étape ?
Il suffirait de faire (dans le fichier /install.php) un test :
si pluxml a déjà été installé un fois (présence d'un compte admin) : on redirige sur la page d'acceuil
si pluxml n'a pas encore été installé : on procède à l'installation.
3) une possible faille
Une faille que à la quelle j'ai moi aussi eu droit dans Blogotext, c'est qu'un utilisateur connaissant le chemin d'un fichier source en XML peut accéder à son contenu, c'est à dire aussi à l'adresse IP de l'internaute (dans le cas d'un fichier d'un commentaire).
Bien sûr, j'ai vu la présence d'un fichier .htaccess censé bloquer cela, mais tous les hébergeurs ne prennent pas en compte ces fichiers. Il me semble que c'est le cas chez Free (l'un des plus gros hébergeurs Français).
Dans Blogotext, j'ai résolu le problème en ajoutant en haut de chaque fichier XML :
< ?php die('rien ici')? ?>
Cet ajout peut aussi rendre non-valide W3C le code source... Moi je n'y vois pas d'inconvénients pour Blogotext vu qu'il utilise sa propre syntaxe xml-like donc pas forcément conforme W3C non plus.
Encore une fois, je sais pas ce que vous en pensez : préférez-vous conserver un code source XML valide coute-que-coute au détriment de la sécurité de quelques utilisateurs, même minoritaires ? À vous de voir.
Autrement, ben, bravo pour Pluxml : je le trouve plutôt complet, surtout pour quelque chose d'aussi léger (400kio). C'est un logiciel agréable à utiliser et qui fait bien ce qu'on lui dit.
Y'a juste le mélange “html” et “php” dans le code qui me rebute un peu (Blogotext sépare complètement les deux), et qui demande des connaissances en PHP quand on veut créer un thème (en plus des connaissances HTML/CSS), mais sinon rien à dire personnellement
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
En effet on a déjà réfléchis sur ce système et l'utilisation de cookies (en vair l'utilisateur) et toujours délicat.
On ne trouve pas cette solution "propre" actuellement et c'est donc pour cela que cette possibilité est délaissée ...
Personnellement j'opterais plus sur l'inscription d'un utilisateur et récupérer ces donnée via php.
Exacte,mais il suffis de dé-commenter la ligne (28) dans le fichier config.php
La vérification est déjà existante, et si tu contourne ce fichier install.php (tout a fait possible) on ne fais que masquer une faille via ce fichier qui resterais sur le ftp.
Pour le reste je ne serais te répondre, après chacun son mode de "template".
Merci sinon de tes remarques constructives.
Ah, ok^^
J'avais pas vu. Faut dire que je n'ai fait que survoler le code source (je suis pas un pro de la POO en plus