Recherche avancée

Sur d’autres sites (4288)

• Anomalie #3035 (Nouveau) : Association de mots-clés et autorisation

  6 août 2013, par Joseph Larmarange

  Création d’un ticket suite à http://permalink.gmane.org/gmane.comp.web.spip.devel/64550

  Cas de figure :
  - des groupes de mots-clés pour lesquels les rédacteurs ont les droits pour ajouter un mot clé de ces groupes.
  - un rédacteur qui visualise un article dont il n’est pas l’auteur et par conséquent pour lequel il n’a pas les droits d’ajouter ou de supprimer un mot-clé.

  Néanmoins, ce rédacteur va voir la liste des mots-clés associés à cet article, avec un lien pour supprimer les mots-clés en question, un lien ’Ajouter des mots-clés’ lui permettant de charger le formulaire d’ajout de mot-clé.

  Si ce rédacteur décide de faire l’une de ces actions (ajout ou suppression), le bloc va se recharger, l’action ne sera pas exécutée et il n’y aura aucun message d’erreur, par exemple pour avertir que l’on n’a pas les droits nécessaires. On a donc une incohérence de l’interface.

  En investigant, j’aperçois plusieurs points qui font défaut.

  En premier lieu, la fonction autoriser_associermots_dist() regarde simplement si un auteur à le droit en général d’associer des mots-clés d’un groupe en fonction de son statut (admin ou rédacteur) mais ne prends pas en compte si l’individu a le droit de modifier l’objet en question.

  Le formulaire EDITER_LIENS du core regarde dans sa fonction charger l’autorisation associerobjets (donc associermots dans notre cas de figure) pour savoir si le formulaire est editable ou non. Dans sa fonction traiter, le formulaire regarde simplement si l’individu a le droit de modifier l’objet en question ou non (mais ne revérifie pas qu’il a les droits d’associer l’objet en question). Par ailleurs, si on n’a pas les droits requis, la fonction traiter ne renvoie pas de message d’erreur.

  Le squelette prive/objets/liste/mots_lies.html ne tient compte ni de #ENVeditable ni d’une quelconque autorisation pour afficher ou non un lien de suppression d’un mot-clé.

  La fonction autoriser_groupemots_afficherselecteurmots_dist renvoie toujours true.

  Propositions d’évolution

  • Faire évoluer l’autorisation associermots pour qu’elle vérifie également, si un $id_objet est passé, que l’invidu a les droits de modifier l’objet en question. Cela permettra que la propriété editable soit correctement renseignée dans le formulaire d’ajout de mot-clé. Par ailleurs, pour les plugins ayant besoin de savoir si quelqu’un a le droit d’associer un mot-clé, cela fera une seule auorisation à vérifier (le problème s’est posé avec coche_mots).
  • La fonction traiter de éditer_liens devrait dépendre de associermot (il faut vérifier que cela n’a pas d’incidence pour les autres tables de liens) et non des droits de modification d’un objet. Ces droits peuvent être différents dans un contexte d’autorisations personnalisées.
  • Cette même fonction traiter doit renvoyer un message d’erreur si on n’a pas les droits suffisants.
  • Le squelette prive/objets/liste/mots_lies.html doit vérifier l’autorisation associermots pour afficher un lien de suppression d’un mot-clé.
  • Par cohérence, la fonction autoriser_groupemots_afficherselecteurmots_dist est modifiée pour renvoyer, par défaut, le résultat de l’autorisation associermots.

• Anomalie #4717 : Erreurs nombre d’argument des filtres

  10 avril 2021, par jluc -

  La PR récupère l’erreur PHP, évite le crash blank et délivre le message d’erreur PHP dans la jolie box d’erreur SPIP. Le pire est évité, et donc il faut intégrer cette PR qui fait du bien.

  Mais l’internaute SPIPien se retrouve avec un message d’erreur en anglais et portant sur le code compilé PHP. Ce code compilé, même le commun des devs PHP ne le connait pas, car à part XRay qui le rend accessible et les core-développeurs qui débuguent le code d’une nouvelle structure SPIP, personne ne va scruter et n’a connaissance du code php généré par le compilateur.

  Pour faire mieux, il y a la piste de la déclaration des arités des filtres. $arite_des_filtres = [[’implode’, 2, 2], [’affdate’, 1, 2]...]. Cette déclaration peut probablement être utilisée au moment de la compilation d’un appel de filtre lorsque le compilateur convertit la structure SPIP #XXX|filtre... en appel PHP.
  Ça permet de détecter une erreur d’argumentcount AVANT l’appel PHP et de fournir un joli message d’erreur SPIP qui fait référence au source SPIP.

  Dans ce cas, la détection d’erreur peut se faire à la compilation.

  Mais il se peut que d’autres erreurs PHP doivent être gérées, avec la strictisation croissante de PHP. Il faudra donc de nouvelles déclarations permettant la détection préventive des erreurs.

  Peut être sur d’autres structures de données que les filtres aussi ?

  Il faut donc développer la capacité d’introspection de SPIP.

  Mais parfois l’erreur n’est pas détectable au moment de la compilation. J’ai évoqué plus haut l’erreur relative au typage des arguments. S’il se confirme que le pb se pose aussi, et vu qu’on peut passer à un filtre un argument calculé dynamiquement, c’est pas lors de la compilation que ça pourra être détecté, mais lors de l’exécution du code compilé.

  Il faut alors prendre chaque erreur PHP possible et voir si/comment le compilateur peut la prévenir.

  Une alternative serait de "traduire" cette erreur PHP de manière à aiguiller le webmestre SPIP.

  Par exemple le message d’erreur de https://www.mail-archive.com/spip@rezo.net/msg81110.html , qui fait référence au source compilé, peut être traduit, par reconnaissance (regexp), analyse du message d’erreur, et calcul du message d’erreur SPIP en « Erreur : dans votre source SPIP, il y un appel au filtre |implode qui n’a pas le bon nombre d’arguments. Ça se passe dans la boucle ’BOUCLE_contenu_article’ : veuillez examiner le code et corriger. » Là en plus, ce serait bien de pouvoir associer le nom du fichier source à la boucle dont on connait le nom. Une capacité d’introspection déjà présente ? ou à développer ?

• Evolution #4102 : Ordre des inclures dans cache/charger_plugins_options.php

  26 février 2018, par placido .

  le define() doit être défini dans le inc/truc, action/truc, etc, ce qui permet bien à d’autres de le définir en amont dans leur options.php.

  Euh, oui, enfin à un autre. Premier arrivé, premier servi.

  Exemple d’un cas vécu : un squelette basé sur Zcore et qui se veut plutôt générique. Un sous-plugin qui fait principalement de la personnalisation de ce squelette (genre content/rubrique-2.html, etc ...). Et bien pas possible à son niveau de redefinir _Z_AJAX_PARALLEL_LOAD sur d’autres zblocs puisque déjà définit plus haut. Bon c’est un cas de figure pas si courant, mais ça existe.

  (et ça m’avait bien saoulé pour le surcharger, j’avais fini par le définir dans les mes_options.php du projet alors que je ne l’utilise jamais et que je voulais le faire dans le plugin de mon projet)

  Oui, c’est précisement ce que je cherche à éviter aussi.

  Ta suggestion est donc de corriger les plugins qui déclarent leurs define() dans leur propre fichier options.php, soit. (Tiens, un autre cas ici)
  Au passage, sans doute serait-il judicieux de rajouter une mention explicite à ce sujet dans la documentation et, tant qu’à faire, recommander l’usage de lire_config/ecrire_config plutôt que l’emploi de constantes de personnalisation.

  Donc on oublie l’insertion de trigger_pre_plugins_options() en tête du fichier charger_plugins_options.php ?
  Dommage, car cela apportait un point d’entrée, ouvrant la voie à une solution pour les (rares mais avérés) cas de définition à n+2.

  Si j’en reviens à ma suggestion B), on aurait pu y faire usage d’un pipeline véhiculant un tableau clé/valeur, modifiable suivant l’ordre de surcharge des plugins,et au final boucler sur chaque rangée ainsi :
  

  defined($cle) or define($cle,$valeur) ;
  

  
  Une solution assez classique en somme.

  Dommage aussi qu’un des principes emblématiques de SPIP (la surcharge en cascade) ne propose pas de gestion homogène pour cette délicate question des constantes.

  Concernant ta proposition de pipeline spip_initialisation, tu as déjà évoqué le sujet il me semble. À quel niveau penses-tu mettre le déclencheur ? Il y a un ticket à ce sujet ?