Recherche avancée

Sur d’autres sites (12971)

• 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...

• Révision 24630 : Ticket #4505 : afficher la révision GIT de SPIP ou des plugins, comme l’on avait ...

  24 juin 2020, par marcimat@rezo.net

  (Refonte de la PR #49 de Real3t.)

  - version_svn_courante() est dépréciée et s’appuie sur la nouvelle fonction decrire_version_svn()
  - pour decrire_version_svn() on ne s’embarrase plus de svn < 1.7, ni de svn.revision (on zip depuis un tag maintenant avec le « Débardeur » et ce fichier n’est plus présent)
  - on introduit decrire_version_git()
  - on introduit version_vcs_courante() qui retourne un texte affichable (tel que "GIT [master : c0f3219b]"), mais peut retourner les quelques données brutes si besoin.

• Evolution #4595 : [Charte privé] Soulignement des liens

  2 novembre 2020, par RastaPopoulos ♥

  Alors oui en accessibilité c’est un des tous tous premiers trucs : ne pas se reposer sur la couleur pour une info, et là c’est pas une petite info : les liens sont, genre… l’élément le plus important de navigation et d’interaction dans une page web, donc si ya un truc à pas rater niveau accessibilité et affordance, c’est bien sur cet élément.

  La règle de base devrait donc être : faut souligner ou autre méthode, mais souligner c’est vraiment le standard, et de nos jours on peut faire des soulignements assez jolis.

  Mais… si ya "de base" dans la phrase, ce n’est pas pour rien. C’est le défaut. Mais suivant tel ou tel contexte, on peut parfaitement styler autrement, car ergonomiquement on sait que telle zone de la page correspond uniquement à une liste de liens. Typiquement un menu parfaitement identifié oui. Ça vaut pour le menu principal en premier lieu bien sûr. Mais aussi pour les colonnes de côtés, dans la plupart des cas on sait ce que sont des listes de liens (comme les liens et boutons qu’on met sous le numéro des objets).

  Là où c’est le plus important de garder le soulignement c’est quand dans un même contexte il y a du texte normal et des liens mélangés. Ça vaut pour les contenus longs évidemment. Mais ça peut valoir dans certains blocs d’infos, de liaisons, tableaux d’infos etc : là il faut savoir ce qui est cliquable sans mettre la souris dessus et donc laisser le défaut il me semble.