SPIP le CMS qui tient ses promesses

Posté par  (site web personnel, Mastodon) . Édité par _dd_, Anonyme, palm123, Benoît Sibaud et Xavier Teyssier. Modéré par Nils Ratusznik. Licence CC By‑SA.
Étiquettes :
28
29
mar.
2022
Internet

Pour ses vingt ans, le système de gestion de contenu (CMS) à l’écureuil avait promis que les mises à jour majeures se feraient plus souvent pour suivre le rythme de PHP. Chose promise, chose tenue SPIP vient de sortir en version 4.1. On en a déjà un peu parlé ici ou là sur LinuxFr.org. Il est temps, maintenant d’en parler plus avant et de voir ce que vous offre SPIP pour vous rendre encore plus facile et plus sûre la conception et la gestion des sites Internet. Ce n’est qu’une sélection, les notes de version sur spip.net sont plus disertes.

Logo de SPIP

Au commencement Ă©tait le PHP

SPIP 4.1 est compatible des versions PHP 7.4 à 8.1. Le support de PHP 7.3 est donc abandonné et cela en conformité avec la décision de ne plus maintenir une compatibilité très large avec les anciennes versions de PHP.

Le détail.

Sécurité

Le système d’authentification (logins et actions) et de stockage des mots de passe en base de données a été complètement revu ce qui améliore grandement certains enjeux liés à la sécurité des authentifications :

  • https est très fortement conseillĂ© sur les sites (d’ailleurs, y en a-t-il encore beaucoup sans ?), en effet, auparavant, SPIP chiffrait le mot de passe de connexion directement en JavaScript, Ă  partir de la version 4.1 il est envoyĂ© en clair ;
  • le hachage du mot de passe a Ă©tĂ© revu, en consĂ©quence, il ne sera plus possible de repasser en SPIP 4.0 (la sauvegarde est ton amie).

Tout est bien détaillé par là.

Bibliothèques

Les différentes bibliothèques utilisées par SPIP ont été mises à jour.

Javascript

  • SPIP

    • Sortable 1.14.0 (depuis 1.13.0)
    • jQuery Form 4.3.0 (depuis 4.2.2)
    • JS Cookie 3.0.1 (depuis 2.2.1)

  • Statistiques

    • d3 7.3.0 (depuis 6.6.0)
    • luxon 2.3.0 (depuis 1.6.0)

  • Plan

    • jstree 3.3.12 (depuis 3.3.8)

PHP

  • Compresseur

    • css-tidy 2.0.0 (depuis 1.1.0)

  • Medias

    • getid3 1.9.21 (depuis 1.9.20)
    • svg-sanitizer 0.14.1

Voir aussi par lĂ .

API, pipeline, typage PHP et tutti quanti

L’API de création et de décodage des URLs de SPIP est partiellement renommée. Il y a maintenant deux jeux de fonctions distincts pour générer l’URL d’un objet et pour décoder une URL.

Les pipelines pre_edition et post_edition ont une clé de donnée supplémentaire transmise (champs_anciens) lors de l’action modifier.

Certains arguments et retours de fonctions commencent à être typés, ce qui est susceptible de créer des erreurs de squelettes, voire des erreurs PHP dans des plugins ou des scripts maisons qui font appel à ces fonctions.

Pour plus de détails.

Et aussi : les traductions ont été mises à jour, le plugin Archiviste ainsi que quelques autres ont été améliorés.

Pour en savoir plus.

Si vous n’êtes pas encore passé à SPIP 4

La recette complète et bien détaillée pour un passage sans stress.

Des petites astuces complémentaires :

  • si le site utilise le portfolio, il est possible de garder le comportement voir au niveau de « Documents et logos » ;
  • si vous ne voulez pas afficher de lĂ©gende aux illustrations (lĂ©gendes qu’elles auront toutes, quel que soit le mode d’insertion, si les champs titre, description ou crĂ©dits ont Ă©tĂ© remplis), vous pouvez utiliser ce modèle ;
  • si, ce qui est la façon la plus simple de mettre Ă  jour, vous utilisez spip_loader et que vous obtenez une belle page blanche pleine de vide Ă  la place, c’est que votre spip_loader n’est pas tout neuf, la version actuelle est le 5.1.0, il faudra le rĂ©cupĂ©rer et l’installer par ftp.

Entre nous, si votre site est dans une version encore plus antérieure de SPIP, ça vaut le coup d’envisager d’en changer le squelette pour lui donner un coup de neuf et le rendre adaptatif et donc lisible aussi de tous les terminaux mobiles (voire, carrément plus accessible). Cela tombe bien, il n’y a qu’à se baisser pour récupérer un squelette HTLM5.

Et si vous avez des questions, l’entraide de SPIP est là pour ça. Sachant qu’en la parcourant, vous aurez peut-être déjà des réponses à vos questions 1.

Le calendrier pour finir

SPIP 4.0 sera maintenu jusqu’à fin juin. Voire, jusqu’à la sortie de la version 4.2, qui est envisagée pour l’été 2022.

SPIP 3.2 ne sera maintenu que pour des correctifs de sécurité jusqu’à fin décembre 2022.

Voir aussi le résumé des versions sur l’annonce de la sortie de SPIP 4.1.

Addendum de retour d’expérience

Si vous avez mis à jour et que tout est inaccessible (sans avoir tout lu des notes de version), mais faites-le avant, c’est mieux (moins anxyiogène déjà), c’est que l’extension PHP sodium n’est pas installée. Cela se passe sur le « panel » de votre hébergeur. Si vous avez un cPanel, c’est dans le PHP Selector.

Un grand merci à celles et ceux qui font de SPIP un outil avec lequel il est tellement agréable de travailler.

  1. C’est l’expérience qui parle. ↩

Aller plus loin

  • # Fin du hachage du mot de passe?

    Posté par  (site web personnel) . Évalué à 3.

    […]https est très fortement conseillé sur les sites (d’ailleurs, y en a-t-il encore beaucoup sans ?), en effet, auparavant, SPIP chiffrait le mot de passe de connexion directement en JavaScript, à partir de la version 4.1 il est envoyé en clair […]

    Je ne comprends pas l'intérêt de retirer le hachage en javascript qui était fait sur le mot de passe lors de l'authentification. Certes, de nos jours, il n'y a plus beaucoup de raisons de ne pas avoir de chiffrement sur les échanges, mais dans un réseau local c'est parfois un peu plus compliqué.

    Je comprends qu'avec le changement de méthode de hachage ça simplifie le processus, ce qui est toujours bien.

    Merci pour cette dépêche, que je n'ai pas vu passer dans l'espace de rédaction…. mea culpa.

    Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

    • [^] # Re: Fin du hachage du mot de passe?

      Posté par  (site web personnel) . Évalué à 7.

      Je ne comprends pas l'intérêt de retirer le hachage en javascript qui était fait sur le mot de passe lors de l'authentification.

      Sans HTTPS, le chiffrement (pas le hachage : si j’ai bien compris, ce qui se passait dans les versions précédentes était que le mot de passe était chiffré côté client par du code Javascript, puis envoyé au serveur où il était déchiffré puis haché, le hash étant alors stocké en base) côté client par Javascript n’apporte pas grand’chose, puisque le code Javascript réalisant le chiffrement est délivré au navigateur à travers une connexion non-sûre.

      Supprimer l’étape de chiffrement par Javascript (donc envoyer directement le mot de passe tel quel au serveur, qui n’a plus qu’à le hacher et le stocker) pour se reposer exclusivement sur le chiffrement de la couche TLS est une bonne pratique.

      Certes, de nos jours, il n'y a plus beaucoup de raisons de ne pas avoir de chiffrement sur les échanges, mais dans un réseau local c'est parfois un peu plus compliqué.

      Si tu es sur un réseau local auquel tu fais suffisamment confiance pour ne pas utiliser TLS, mais que tu aimerais quand même que ton mot de passe soit chiffré, c’est que tu ne fais pas tant confiance que ça à ce réseau local et donc que tu devrais activer TLS. :)

      • [^] # Re: Fin du hachage du mot de passe?

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Les deux ne s'excluent pas… Si j'en crois ce que font les gestionnaires de mots de passe et PrivateBin

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: Fin du hachage du mot de passe?

          Posté par  . Évalué à 2.

          PrivateBin C'est un peu différent, ils font du chiffrement côté client pour que le serveur n'est jamais la donnée en clair. TLS ne sécurise que le canal de communication les données sont en clair une fois sur le serveur.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Fin du hachage du mot de passe?

      Posté par  . Évalué à 2.

      C'est parce qu'il n'est pas possible, ou bien compliqué, de s'assurer que pile le même hashage sera fait entre JS et PHP (ce n'était pas le cas et des gens n'arrivaient plus à se connecter). Il vaut donc mieux se reposer sur une technologie très largement éprouvée pour sécuriser l'échange entre client et serveur (https donc), plutôt que mal le faire à la main nous-même.
      Des explications lĂ  : https://git.spip.net/spip/spip/issues/5059
      Ou lĂ  : https://git.spip.net/spip/spip/issues/4927#issuecomment-33281

    • [^] # Re: Fin du hachage du mot de passe?

      Posté par  . Évalué à 3.

      Je ne sais pas précisément comment marchait l'authentification, mais l'expérience montre qu'un certains nombre de développeurs raisonnent de la façon suivante :

      • je veux que les utilisateurs s'authentifient en HTTP
      • mais si j'envoie le mot de passe en clair, n'importe quel intermĂ©diaire peut voler le mot de passe
      • donc je vais ĂŞtre malin et hacher le mot de passe m avec une fonction Ă  sens unique h sur le client, puis envoyer h(m), comme cela le mot de passe ne circulera pas en clair.

      Ça paraît malin, sauf que…

      • pour s'authentifier auprès du serveur, il n'y a plus besoin du mot de passe m, juste de la valeur de h(m)
      • et ça tombe bien pour l'homme du milieu qui va voir passer cette valeur
      • il lui suffit donc d'Ă©crire son propre client qui enverra cette valeur (sans avoir besoin de connaĂ®tre m)

      Résultat : on n'a rien gagné en sécurité.

      Il y a évidemment des protocoles plus complexes qui permettent de s'authentifier sur un canal qui est espionné. Mais à ma connaissance, pour résister à un adversaire passif, ils demandent de partager un secret (ce qui veut dire stocker le secret sur le serveur) ou… reposent sur de la crypto à clé publique (type échange de Diffie-Hellman). Et si on veut résister à un adversaire actif, il faut rajouter une forme de PKI (certificats).

      TL;DR: il y a un protocole qui permet d'échanger sur un canal non-sûr, ça s'appelle TLS.

  • # Le petit projet qui a tout d’un grand

    Posté par  (site web personnel) . Évalué à 1.

    SPIP, le petit outil pour créer des sites web basiques, que j’utilise pour mon blog perso notamment. D’ailleurs il faudra que je le mette à jour un de ces jours.

    Mais intéressant à souligner, SPIP c’est aussi un outil pour créer des sites webs complets. J’ai encore vu très récemment une association nationale qui a réalisé une grosse mise à jour de son site sous SPIP et qui n’a pas à rougir face aux alternatives plus répandues.

  • # Mise Ă  jour de la dĂ©pĂŞche suite au passage Ă  SPIP 4.1

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    Il fallait installer une extension PHP sodium qui ne l'Ă©tait pas en ce qui me concerne.

    Je l'ai précisé parce qu'on n'est pas forcément spécialiste de l'hébergement et du php quand on a des sites.

    « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.