Recensement des bugs de Pluxml blog beta 3

Skyline · mars 2008

Pour aller dans le sens de l'annonce faite précédement nous avons corriger tous ces bugs qui trainent depuis longtemps dans Pluxml blog beta 3. N'ayant pas utilisé Pluxml depuis longtemps à cause de mon absence j'ai besoin de vous pour faire remonter les bugs.
Le système est simple, nous tenterons de corriger au plus vite chaque disfonctionnement que vous signalerez mais pour cela pensez à nous faire une description précise et détaillée du bug.
Merci à vous

Diti · mars 2008

Veuillez, s'il-vous-plaît, utiliser ce code de mise en forme pour votre message :

[b]Résumé du bug :[/b]
Un court résumé de quelques mots

[b]Endroit où le bug est constaté :[/b]
Donner un endroit (p. ex. gestionnaire d'images) ou accessoirement une URL

[b]Description du bug :[/b]
Une description détaillée du bug (n'hésitez pas à faire une capture d'écran)

Bugs rapportés :
OK - bug B3-1 : Caractères à entités en nom de commentateur ;
OK - bug B3-2 : Article sans titre dans la liste des articles ;
Full path disclosure de deux fichiers ;
Pas de catégorie à accent possible ;
Aucun site de posteur de commentaire ;
Atom : date pouvant être erronée ;
Balise lien non fermée causant une impossibilité d'édition.

Réflexions :
À l'installation, problème d'encodage. Utiliser des entités HTML ?
Songer à passer en Unicode, vu les petits problèmes que ça peut éviter.

Prioritaire :
Attaque par CSRF.

gcyrillus · mars 2008

Résumé du bug :
Problèmes de caractères accentués dans les posteurs de commentaires

Endroit où le bug est constaté :
affichage des commentaires (interface public) et editions (interface d'administration).
Si un caractéres accentués est dans le nom de l'auteur d'un commentaire ' ceux-ci ne sont plus affichées , il faut manuellement corrigé le fichier.

Description du bug :
le CDATA , n'est pas reinjecté dans le fichier xml a la sauvegarde aprés édition , d'ou le bug qui ne permet plus de parser le fichier correctement.

Skyline · mars 2008

Corrigé.
Par contre je ne met pas en téléchargement une nouvelle version à chaque bug corrigé, je vais attendre que d'autres corrections soient intégrées.

gcyrillus · mars 2008

oui , cela va de soi .

Content de voir le 'créateur' de retour

Autre petit defaut :
Résumé du bug :
Nouvel article Sans titre

Endroit où le bug est constaté :
interface publique et administration

Description du bug :
A la premiere sauvegarde d'un article , si l'on a omis de donner un titre,
il n'y a aucun lien cliquable vers l'article complet ou son edition.

perso .Etourdi, je regle ce defaut en inserer d'office un titre :
extrait code du fichier article.php:

}else{
	$title = $cat = $chapo = $cat_num = $art_num = NULL;
	$author = $_SESSION['author'];
	$date = array ('year' => date('Y'),'month' => date('m'),'day' => date('d'),'time' => date('H:i:s'));
	$content = '<p></p>';
	$file_num = $admin->nextId();
	$title_page = "Nouvel article";
	$allow_com = $admin->config['allow_com'];
	$title="Nouvel Article";
	}

Skyline · mars 2008

Corrigé

Black_H · avril 2008

Résumé du bug :
Faille de type 'full path disclosure', affichage du path complet du fichier.

Endroit où le bug est constaté :
Header de l'administration :
http://127.0.0.1/pluxml/core/admin/top.php
http://127.0.0.1/pluxml/core/templates/defaut/template.php

Description du bug :
Simplement se rendre sur la page ^^ Ce type de bug peut être très utile cumulé à d'autre.

Solution: empêcher un accès externe à ces fichiers.

fightsoul · avril 2008

Résumé du bug :
Impossibilité de créer une catégorie avec un accent.

Endroit où le bug est constaté :
Administration > catégories.

Description du bug :
On ne peut pas mettre d'accent dans une nouvelle catégorie, on est obligé de créer la catégorie sans accent et ensuite de l'ajouter.

Tikehau · avril 2008

Résumé du bug :
Lorsque le site est précisé dans la saisie d'un commentaire le lien qui devrait s'afficher sur le Nom/Pseudo ne peut se constituer

Endroit où le bug est constaté :
dans functions.php sur case 'com_author':

Description du bug :
syntaxe erronée :
if($option = 'link' && $pluxml->coms->f('site') != 'http://'){
syntaxe corrigée :
if($option == 'link' && $pluxml->coms->f('site') != 'http://'){

Tikehau · avril 2008

Résumé du bug :
Dans le Fil Atom on trouve une petite erreur de constitution du fil.

Endroit où le bug est constaté :
dans atom.php la ligne :
<updated><?php echo $pluxml->a_article[0]; ?></updated>
peut être substituée par celle-ci :
<updated><?php echo $pluxml->result->f('date'); ?></updated>
Conséquence : la balise description prendra la date d'update du premier article écrit.

Description du bug :
Dans le fil constitué la fonction a_article[0] ne ramène rien :
<description> ... le blog à l'xml</description>
<updated></updated>

Dans class.pluxml.php cette partie déjà déclarée obsolète pourrait alors être supprimée ou bien adaptée pour ramener le résultat escompté :
Citation : // Version obsolète ? => question est posée dans le code d'origine
var $a_article; # Tableau d'articles à afficher
var $a_index; # Index du tableau des articles
function loopArticles(){
if($this->a_index < count($this->a_article)-1){
$this->a_index++;
return true;
}else{
return false;
}
}

PS : comment récupérer autrement la date de création du Blog si c'est bien d'elle dont il s'agit ?

Steph0 · avril 2008

Salut,

Mon rapport va peut-être paraître flou mais bon comme il s'agit manifestement d'un bug :

Résumé du bug :
Une balise liens non fermée transforme l'article en liens géant et a plusieurs autres conséquences.

Endroit où le bug est constaté :
Page d'édition de l'article dans la partie administration, partie 'commentaires' au niveau de l'article lui-même.

Description du bug :
A la suite d'un article publié, j'ai pu observé qu'une balise lien n'était pas fermée. Las ! L'erreur faite, pluxml a eu un bug. Ainsi, l'article publié, je n'ai plus pu éditer l'article. En effet, la zone d'édition était devenue un lien géant menant vers le liens non fermé, et le boutons enregistrer ne fonctionnait plus.

Par ailleurs, il était alors devenu impossible de mettre un commentaire sur l'article. En effet la zone permettant d'écrire le commentaire était alors un lien géant tout comme la zone d'édition.

Je ne peux vous fournir de screenshoot, il faudrait d'ailleurs plutôt une vidéo. Mais si je peux vous fournir le contenu d'un log ou autre de pluxml qui pourrait contenir un rapport d'erreur (j'ai sauvegardé l'ensemble de pluxml buggé avant de résoudre le problème).

Résolution :
La résolution fût simple, j'ai juste eu à télécharger le fichier de l'article et à fermer la balise en local puis remplacer le fichier buggé par le fichier 'propre'. Après ça tout est rentré dans l'ordre.

Steph0 · avril 2008

Salut,

Résumé du bug :
Un lien trop long dans un commentaire déborde.

Endroit où le bug est constaté :
Commentaires

Description du bug :
En vérité, tout commentaires comportant un lien trop long déborde du cadre :

http://img178.imageshack.us/img178/2136/screenvs8.jpg

Par ailleurs, j'en profite pour demander s'il serait possible d'uitliser les balises <a>,<strong>,<em> dans les commentaires de Pluxml ?

Diti · avril 2008

Hum, ça c'est un problème d'overflow CSS, c'est ton thème qui est en cause. Je te conseille de lire ceci.

Concernant les balises, on s'en occupera plus tard, car pour des raisons de sécurité (XSS, quand tu nous tiens), il faudrait créer un système de vérification de balises autorisées ou interdites. Et la priorité est d'abord le passage en PHP 5.

klav · juin 2008

Résumé du bug :
Lors de l'édition d'un article, il est proposé d'autoriser les commentaires pour cet article même lorsqu'il a été précisé, dans les options de configuration générales, que les commentaires sont proscrits.

Endroit où le bug est constaté :
Formulaire d'édition d'un article (articles.php).

Description du bug :
Dans Administration > Paramètres > Autoriser les commentaires, je choisis "Non". Quand j'édite un article ensuite, il m'est toujours proposé d'autoriser les commentaires.

Proposition de patch :
Je propose d'ajouter un test conditionnel dans articles.php avant l'affichage du champ Autoriser les commentaires :

<?php if ($admin->config['allow_com'] == 1) : ?>
  <p class="field">
    <label>Autoriser les commentaires :</label></p>
    <?php printSelect('allow_com', array('1'=>'Oui','0'=>'Non'), $allow_com);?>
<?php endif; ?>

marama · juin 2008

Bonjour,

Sachez tout de même que même si vous autorisez les commentaires sur un article et que la configuration générale du blog l'interdit, c'est elle qui prime.
Dans un soucis de compréhension, effectivement ce test conditionnel sera étudié.
Cordialement

gcyrillus · octobre 2008

bonjour,

dans le cas ou pluxml est vide d'article ou qu'une requete est faites vers une catégorie ou un article inexistant , on se retrouve avec un message d'erreur et un corps vide

.

Je propose eventuellement un test pour ce cas de figure afin d'eviter ce 'defaut' eventuel.

voir : http://forum.pluxml.org/viewtopic.php?pid=8084#p8084

++

Recensement des bugs de Pluxml blog beta 3

Réponses