Recherche avancée

Sur d’autres sites (12031)

• Anomalie #3846 (Nouveau) : La compression JS retire des espaces dans des chaines entre quotes

  25 octobre 2016, par b b

  Je viens de remarquer que dans certains cas, la compression JS retire des espaces dans des chaînes entre quotes, cf :

  http://zone.spip.org/trac/spip-zone/changeset/100159

  Le script passé à travers le filtre compacte est le suivant :

  http://zone.spip.org/trac/spip-zone/browser/_plugins_/gis/trunk/lib/leaflet/dist/leaflet.js

  En y regardant de plus près, des chaînes comme " leaflet-" deviennent "leaflet-" après compression, et comme celles-ci sont utilisées pour définir des classes css à appliquer sur des éléments du DOM, on se retrouve avec des attributs class comme "mahcinbidule" au lieu de "mahcin bidule".

  Le truc étrange, c’est que toutes les chaînes du type " machine" ne sont pas impactées, seulement certaines le sont...

• Anomalie #3688 (Nouveau) : Différence de traitement du IN selon qu’un critère est facultatif ou pas

  9 février 2016, par tcharlss (*´_ゝ｀)

  Description :¶

  Il semble y avoir une différence de traitement selon qu’un critère est facultatif ou pas, quand dans l’environnement, la valeur correspondant au critère est un array. Dans un cas, ça fait bien un WHERE machin IN (x,y,z), dans l’autre, ça fait un WHERE machin = truc bizarre.

  Pour reproduire :¶

  Soit un squelette qui en inclus un autre :
  

  Squelette inclus :
  

  #ID_AUTEUR
  

  Au niveau de ce dernier, #ENV{id_auteur} est un tableau qui contient des strings, au lieu de int :
  

  array (size=10)
    0 => string ’1’ (length=1)
    1 => string ’2’ (length=1)
    etc.
  

  Avec le critere facultatif {id_auteur ?}, la boucle passe, on a bien un IN dans le WHERE :
  

  auteurs.id_auteur  IN (1,2,3,4,5,6,7,8,9,10)
  

  En revanche avec le critere id_auteur, ça ne fonctionne pas :
  

  auteurs.id_auteur = (2 1 (3) : 4)
  

• Anomalie #4497 : [robustesse du hash du mot de passe utilisateur] : spip_auteurs.htpass

  28 mai 2020, par cedric -

  le htpass est utilisé pour la génération des fichiers htpasswd apache qui servent donc à filtrer l’accès au site si on veut, pour des raisons techniques X ou Y.
  On ne peut pas faire une mise à jour qui vide les tables existantes, car cela invaliderait totalement les mots de passes sur les sites qui utilisent cette feature, et il faudrait que tout le monde change son mot de passe.

  Ce qu’on peut faire c’est utiliser une fonction surchargeable pour générer le htpass au lieu de directement appeler crypt, ce qui permettrait :
  - de desactiver cette feature sur les site qui le veulent
  - ou d’utiliser une autre fonction de hashage dans le futur pour ceux qui le veulent.

  Dans un second temps, on peut aussi ajouter une config qui serait à off par défaut sur les nouveaux sites, et mise à on lors des upgrades, et qui permettrait d’activer ou non ce htpass.
  Mais il faut alors aussi gérer les implications sur l’interface qui permet de créer les htaccess : si on a pas les htpass en base il faut que le webmestre soit prévenu, et lui expliquer qu’il doit activer cette config+ chaque utilisateur doit changer son mot de passe...