Gandi et Jabatus, une histoire d'amour

« Cyrille Borne est le Maître Eolas du libre francophone »

C'est la réflexion que je me suis faite lorsque je me suis aperçu que je n'avais pas besoin de suivre son flux RSS pour avoir ses derniers articles. De toute manière, à présent, je ne peux plus suivre son flux RSS.

J'utilisais jusqu'à présent l’agrégateur de flux minimaliste qu'est Kriss_feed. Il fonctionnait très bien, jusqu'à ce que je me rende compte que je ne récupérais plus les flux d'un certain nombre de sites : les deux de Cyrille Borne, et celui de Bronco. J'ai donc forcé la mise à jour et suis tombé sur une erreur qui avait déjà été remontée par Cyrille himself en 2014.

Comme il n'y a pas vraiment de solution proposée, je me décide à contrecœur à essayer FreshRSS. Le problème est identique, mais ici les logs me fournissent un début d'explication :

A feed could not be found at http://www.cyrille-borne.com/feed/rss; the status code is 403 and content-type is text/html [http://www.cyrille-borne.com/feed/rss]

Une erreur 403, autrement dit un blocage. Je fais un whois rapide : oui, Bronco et Cyrille sont tous les deux chez O2Switch, l'hébergeur utilisant Jabatus, une solution maison de protection de leurs serveurs. Soit dit en passant, si j'ai terriblement besoin de ces flux RSS, c'est que Jabatus a blacklisté d'office tous les points de sortie de tous les VPN que j'utilise, rendant la lecture de ces blogs impossible sans proxy ou sortie du tunnel…

Je vais donc sur le site dédié pour vérifier si l'adresse IP de mon instance Gandi (donc pas nécessairement le plus petit hébergeur) n'a pas été bloquée. Une liste de ces IP est disponible dans la FAQ.

Sur les 13 adresses en France, une seule a été bloquée, ajoutée à la liste il y a 3 jours, ce qui correspond à peu près au moment où j'ai perdu le fil. C'est bien ma veine… Je fais donc une demande pour ne plus être listé, ce qui devrait être fait « en quelques minutes ».

Vérification après une petite demi-heure : aucune des adresses de Gandi n'est bloquée par Jabatus… et pourtant il n'est toujours pas possible de récupérer les flux RSS. Quelques heures d'attente plus tard, et les blogs sont de nouveau accessibles !

Victoire ? Non. Trois jours plus tard, nouveau blocage. La raison invoquée est toujours la même : « spam web ». Je suppose qu'un script doit tourner sur l'un des SimpleHosting Gandi et va spammer les commentaires d'un des 47000 clients O2Switch. Que ce client, plutôt que d'appliquer un filtrage plus fin, un antispam sur ses commentaires ou j'en passe, choisit la solution de la facilité en appuyant sur un hypothétique bouton « Bloquer avec Jabatus, la solution bourrine qui va bloquer tout un ensemble de vhosts sans chercher à faire le distinguo ». (voir EDIT ci-dessous)

Dans tous les cas, voilà où j'en suis jusqu'à présent. J'ai identifié le problème, mais ne peut plus rien y faire, à part écrire un mail au support d'O2Switch pour leur expliquer qu'en tant que client Gandi j'ai un problème avec leurs services, et inversement contacter Gandi pour leur expliquer qu'un script pollueur doit tourner sur l'un de leurs hébergements.

D'où ce billet de blog, parce que je n'aime pas me répéter, et pour que ça serve à d'autres qui pourraient être dans le même cas que moi.

EDIT 11h30 : Il n'y a pas à dire, chez O2Switch le support est au top. Quinze minutes après mon mail, je reçois cette réponse :

L'un de mes collègues est en train de mettre en liste blanche l'adresse Ip de Gandi. (c'est un fournisseur qui peut être contacté et en général très propre sur son réseau).
Parallèlement nous sommes en train de faire des recherches précises pour soumettre un abuse à Gandi. La difficulté étant de trouver l'hôte source (tcpdump des posts pendant plusieurs heures..), car si on donne juste une IP sortante de Gandi à leur abuse, ils ne vont pas en faire grand chose, je présume.

J'ai vu votre billet. Je me permettrai juste de vous apporter une précision sur le système en place.

Pour qu'une IP soit bloquée par Jabatus, il faut vraiment qu'un robot soit excessivement virulent.
Un seul site qui réceptionne du SPAM, une attaque bruteforce, ou des tentatives de hacks, ne suffit pas à bloquer une IP.

Pour qu'une IP soit blacklistée, il faut que des 10ènes de sites soient concernés par une attaque similaire, d'une même IP, dans un laps de temps de quelques minutes. En gros : que le botnet soit vraiment préjudiciable pour tout le monde, et non pour un site en particulier.
Donc, Jabatus n'est pas vraiment une méthode de "bourrin", mais son blocage est vraiment réfléchi sur du factuel et sur un impact mesuré important pour les clients hébergés, qui n'ont au final rien demandé..
Nous sommes hébergeur, on nous demande qu'un site hébergé soit accessible rapidement ! Jabatus est vraiment un plus, outil sur lequel nous travaillons en permanence et qui utilise des techniques de WAF, d'analyses avancées de logs. Pas une simple liste qui trouve une IP et bloque à l'aveugle.

Ces précisions légitimes sur Jabatus me semblent justes, maintenant je me sens tout miséreux d'avoir douté de ce système :)

PIA utilise des DNS menteurs

On m'a rapporté que Private Internet Access, le VPN qui sponsorise Linux Mint, utilise des DNS menteurs… Des sites comme Kickass Torrents n'existent pas, selon eux :

$ ping kat.cr
ping: unknown host kat.cr

C'est bien connu de leurs utilisateurs Linux, le client officiel PIA change le fichier /etc/resolv.conf pour y insérer ses propres DNS lors de la connexion, avant de le remettre à son état d'origine à la déconnexion :

nameserver 209.222.18.222
nameserver 209.222.18.218

Ça pose non seulement le problème du DNS menteur, mais également celui de dnsmasq (cache local des requêtes DNS) ou de son propre DNS installé en réseau local. Sans parler du fait que ces serveurs sont localisés aux États-Unis, le temps de réponse est loin d'être optimal. Du coup, comment outrepasser cela ?

Modifier le comportement du gestionnaire beta

Mon raisonnement était simple : le gestionnaire est un script, on le modifie pour ne pas changer resolv.conf, problème réglé. Mais ce n'est pas aussi simple. Le client officiel est installé dans ~/.pia_manager/. En se baladant un peu, on voit que c'est du Ruby, on essaie d'en ouvrir un et…

"Ruby script '"+__FILE__+"' is protected by RubyEncoder and requires a RubyEncoder loader to be installed.

Hum. Pas cool.

Ne pas utiliser le client beta

La seconde solution qui vient à l'esprit est d'utiliser la connexion en PPTP, telle que décrite dans le support. Eh, on peut même utiliser l'OpenVPN. Bon, sur certaines machines ce n'est pas aussi simple à installer, et l'on perd la connexion automatique au démarrage, mais on y gagne quelques 400 Mo de disque et 200 Mo de RAM, ce qui n'est pas rien…

Problème avec Linux Mint 17.2 : la connexion en OpenVPN ne se fait pas parce qu'il n'y « a pas de secrets VPN valides ». Pas de prompt de mot de passe. Il semble que ce soit un problème récurrent sous dérivés d'Ubuntu 14.04 (qui n'est pas officiellement supportée par PIA, alors que la 12.04 l'est… Grrrr, 3 ans de retard, c'est une éternité, on dirait le support Steam).

La solution est assez simple, en plus du paquet network-manager-openvpn il faut le paquet network-manager-openvpn-gnome :

sudo apt-get install network-manager-openvpn-gnome

Et on a enfin un prompt pour le mot de passe !

Le fichier /etc/resolv.conf n'est pas modifié, problème résolu :

nameserver 127.0.0.1
nameserver 80.67.169.12
nameserver 80.67.188.188

Donc, ça marche, mais quelques points noirs :

  1. Il faudra enregistrer le mot de passe. Pour chacune des connexions. Cinq bonnes minutes de setup, ça reste raisonnable.
  2. La connexion n'est pas automatique au démarrage. Il est cependant possible de la lancer automatiquement lors d'une connexion wifi, mais cela se fait réseau par réseau.
  3. Possible DNS leak. J'invite à vérifier avec un outil en ligne que vous n'êtes pas sujet à ce problème.

On s'amuse à faire un ping sur un domaine bloqué :

$ ping kat.cr
PING kat.cr (195.3.147.99) 56(84) bytes of data.
^C
--- kat.cr ping statistics ---
27 packets transmitted, 0 received, 100% packet loss, time 26199ms

Voilà, donc outre le DNS menteur, les IP semblent bloquées également. Oui, les 8 qu'utilise Kickass. The Pirate Bay, lui, fonctionne correctement…

EDIT 15 septembre 2015 : Certains sites comme Kickass ne sont plus bloqués au niveau IP.

Bye bye Opera

Un peu à la manière de Timo, je ne peux plus utiliser Opera.

J'avais changé de Firefox à Opera en décembre dernier, agacé par la lourdeur du panda (quand une simple navigation web parvient à prendre plus de 3 Go de mémoire, avec obligation de redémarrer toutes les deux heures).

J'aimais bien Opera, c'était léger, les préférences, le Speed Dial, les signets, tout ça se faisant dans une seule fenêtre par HTML/CSS/JS, un peu à la manière de Chromium, en mieux… Et puis la barre de recherche unifiée, avec ajout simplifié de moteurs, c'est un régal (j'avais mis un raccourci : taper `srt Halt and Catch Fire` m'envoyais directement sur les sous-titres Addic7ed pour cette série, par exemple).

Cela ne me dérangeait pas de ne pas avoir d'outil d'exportation des favoris. Cela ne me dérangeait pas de ne pas avoir les outils des versions antérieures à Opera 12. Cela ne me dérangeait pas de ne pas avoir les groupes d'onglets de Firefox, ou bien ses meilleurs outils de dev web (je ne passais sous Firefox que pour développer, du coup). Ne plus avoir de drag'n'drop sur les téléchargements et devoir faire trois clics plutôt qu'un pour en arrêter ? Bof, on s'y fait.

Mais certains points ont commencé à m'agacer. Gérer correctement ses favoris était devenu plus compliqué. Synchroniser un profil entre un Linux et un Windows installés sur une même machine est devenu un calvaire : obligation d'utiliser le service en ligne d'Opera, qui ne synchronise pas les onglets ouverts (le partage d'un dossier de profil sur une partition commune fait étrangement planter à répétition Opera, alors qu'il est une routine pour Firefox).

Et puis, j'avais désactivé Flash. Ça allait sur la plupart des sites, HTML5 est bien ancré. Jusqu'à ces dernières semaines. Jusqu'à ce que Flash soit bloqué sous Firefox, maintenant que j'y repense. Twitch et Dailymotion ne voulaient plus se lancer, Youtube m'affichait toujours un petit écran « Télécharger Flash » avant de lancer la vidéo en HTML5… N'empêche, ne pas pouvoir regarder des gifs sur Facebook ou sur Twitter, c'est exaspérant, n'est-ce pas ?

La goutte d'eau ? À présent, même les vidéos en HTML5 ne fonctionnent plus : j'ai du son, mais la vidéo reste noire. Seul Youtube arrive à passer. Donc, basiquement, je ne peux utiliser Opera que pour aller sur Youtube, lire et écrire, et c'est tout.

Donc bye by Opera. Je retourne sous Firefox comme navigateur principal, tu seras peut-être un navigateur d'appoint, mais guère plus. Ce n'est pas que tu sois limité : tu es un Chromium amélioré. Mais tu ne remplis plus ta part tacite du contrat qu'on avait passé toi et moi.

Quand « lightweight » signifie « fat and no features » : les CMS file-based

Note préalable

Ceci est plus un billet d'humeur qu'un comparatif objectif. Il a été écrit pendant une nuit où je cherchais désespéremment un CMS simple, après avoir goûté aux déceptions que sont Grav et Phile.

Oh, et j'entends bien entendu par backend toute interface d'administration permettant de gérer le contenu affiché en frontend. Il s'agit ici plus d'éviter les longues répétitions.

Préambule

J'adore quand quelque chose de simple devient complexe… Les CMS file-based, j'aime bien. C'est facile à mettre en place, ça s'installe partout, et les sauvegardes se font rapidement.

Habituellement, j'utilise pour ça PluXML. C'est une valeur sûre. Pour les sites statiques, sans blog par exemple, j'utilise plutôt GetSimple que je trouve plus rapide à appréhender pour un client (ajouter une page se fait en un clic, on modifie le menu en glissant-déposant, là où il faut une manipulation tirée d'un autre âge pour PluXML sur ce point).

Mais j'ai voulu voir un peu la concurrence, trouver encore plus simple, si possible avec un éditeur Markdown et sans fioritures (si je veux un blog ou un flux RSS, ce doit être un plugin).

Eh bien, c'est un peu le parcours du combattant.

Le but

Disons que je cherche un CMS avec une administration, pour deux raisons.

La première, c'est que si les CMS sans backend sont intéressants dans le cadre d'une utilisation d'un contenu édité en groupe (cas d'une documentation mise sur serveur git, par exemple) ou seul sur une même machine, ils sont bien moins intéressants quand on est sans cesse en déplacement d'une machine à l'autre ou si le groupe en question n'a pas accès au serveur.

Un exemple parlant : lorsque je suis sur une autre machine que la mienne, pour prendre des notes, j'aime bien utiliser mon Shaarli en mode privé. Ainsi, je ne laisse pas de trace chez mon hôte, et j'évite de déconnecter son Facebook/Gmail/etc. pour simplement prendre quelques notes. C'est impossible à réaliser avec un CMS sans backend.

La seconde raison, c'est que si je voulais faire un site sans backend, autant le faire en local, tout en HTML/PHP ou avec les outils qui vont bien (Hugo je pense à toi). Le seul intérêt des CMS flat file sans administration, c'est de mettre l'accent sur le contenu, en simplifiant l'écriture de celui-ci à sa base : un simple écrit dans un fichier texte.

Au cas où, StaticGen liste les générateurs de site statique, et code.makery a écrit un article intéressant sur le sujet : Making Content Editor and Web Developers Happy Again.

Durant les recherches effectuées pour écrire cet article, je suis également tombé sur Sculpin, un générateur de site statique en PHP fonctionnant de manière similaire à Composer. Utile si vous ne voulez pas vous farcir du Ruby, du Node.js, du Python ou du Go…

Comparatif subjectif

xkcd - Standards

Prenons comme base de comparatif PluXML. PHP, 200 fichiers, taille nu 1,1 Mo. Template PHP. Flux RSS, blog, pages statiques, pagination, commentaires, plugins, panneau d'administration, multi-utilisateurs, pages privées, gestionnaire de fichiers, multi-langues, thèmes, sitemap… Bref, assez complet.

Pour info, encore à des fins comparatives, WordPress : PHP + MariaDB, 1330 fichiers, 20,9 Mo. Template PHP. Niveau fonctionnalités, assez proche de PluXML, auquelles on peut ajouter : plus de plugins, plus de thèmes, plus grande communauté, quick-post, et quelques améliorations au niveau typographie…

Note sur la méthodologie

Pourquoi regarder le nombre de fichiers ? Tout simplement parce qu'il est bien plus simple de comprendre comment fonctionne un code qui tient en 8 fichiers qu'en 2500. Si comprendre et pouvoir maintenir un minimum le code que vous faites tourner sur votre serveur ne vous intéresse pas, pour moi ça a son importance.
Pourquoi regarder la taille ? Sur certains hébergements, ça a son importance. Ici, cela va surtout servir à démontrer un point : ce n'est pas en faisant plus de lignes de codes que vous aurez plus de fonctionnalités, il semble même que ce soit l'inverse…
Le template est donné à titre indicatif uniquement. Généralement ils ne sont guère complexes.

Grav

Je commence par Grav, très eye candy, sympathique. PHP, 1540 fichiers, taille nu 8,9 Mo. Template Twig.

Déjà il y a quelque chose qui cloche. Avec un poids pareil, on pourrait s'attendre à trouver plus de fonctionnalités que PluXML. Eh bien… Non. Ça, c'est juste pour parser des fichiers Markdown et les afficher en un site statique (ou un blog, en jouant avec les sous-dossiers).
Vous voulez un flux RSS ? Ajoutez 300 ko.
Vous voulez un sitemap ? Ajoutez 10 ko.
Etc. On se retrouve avec bien 10 Mo pour à peine le tiers des fonctionnalités d'un CMS qui en fait 10 fois moins… Et le meilleur ? Avec tout ça, il n'y a même pas d'administration ! Certes, c'est le principe des flat file CMS, mais on aurait pu s'attendre à ce qu'un plugin soit présent pour justifier tout ça…

Donc je surveillerai Grav, mais pour le moment il me semble bien trop volumineux pour pouvoir clamer être « léger ».

Dropplets

Dropplets est un blog. Rien de plus. PHP, 47 fichiers, 1,4 Mo. Template PHP.

Pas de flux RSS, pas de plugins, mais il a un panel d'administration, lui ! Celui-ci se résume à quelques variables habituelles (mot de passe, nom du site…) et un formulaire d'envoi de fichier. Vous devez donc écrire en local avant d'envoyer via le panel. Concept intéressant, auquel je vois deux bémols :

  1. Il n'y a pas possibilité d'envoyer une image ou un quelconque media par le panel, donc obligation d'utiliser autre chose pour le faire.

  2. Dropplets renomme le fichier envoyé en utilisant la première phrase. Ça m'a valu de ne pas pouvoir supprimer ces fichiers sur mon FTP pour une raison que j'ignore. Il a fallu que je passe par la console SSH pour arriver à faire un rm -rf propre. Pourquoi ne pas utiliser un timestamp, comme tout le monde ?

Donc minimaliste, et aucune possibilité de modification…

Phile

Phile est amusant. Il commence comme un fork de Pico. PHP, 710 fichiers, 2,0 Mo. Template Twig.

Juste un site statique. Comme pour Grav, on peut jouer avec les sous-dossiers pour arriver à faire un blog. Et comme pour Grav, tout se passe dans les plugins. Là où ça devient hilarant, c'est sur le plugin d'administration (PhileAdmin).

D'une, il n'y a que son créateur qui semble arriver à le faire fonctionner. De deux, que l'on essaie de l'installer avec Composer (méthode recommandée par l'auteur) ou manuellement, on se retrouve avec un plugin qui pèse 30 Mo. Oui, vous avez bien lu. 30 Mo pour un backend qui ne sert qu'à ajouter, modifier ou supprimer des pages. Oh, et l'éditeur Markdown pour ce panel n'est même pas inclut, c'est un plugin supplémentaire ! Bien entendu, aucun support pour les images et autres médias en administration… Là je trouve que c'est du grand art. La faute à des dépendances Symfony qui semblent indispensables pour l'auteur, quand du code PHP pur lui donnerait le même résultat en quelques 300 Ko maximum.

Donc Phile, c'est bien, mais encore une fois il faut passer par la case FTP/Git.

Pico

Pico est souvent cité comme une référence. PHP, 909 fichiers, 2,6 Mo. Template Twig.

Site/Blog qui se dit « simple & blazing fast ». Tellement « simple » qu'il faut :

  1. Cloner le dépôt git ou télécharger l'archive,
  2. Télécharger Composer et le lancer,
  3. Envoyer le tout sur le serveur.

Parce que proposer une release zippée avec toutes les dépendances, c'est so-2012

Encore une fois, tout se passe dans les plugins. Et là, pour le coup, rien à dire. Le panel d'admin fonctionne, il fait 1,1 Mo, mais avec ça vous avez un file manager, un upload des images et un éditeur Markdown. M'enfin, si vous voulez, il y a aussi possibilité de passer par Draft.

Kirby

Kirby est génial. PHP, 670 fichiers, 5,6 Mo. Template PHP.

Backend intégré d'office, système de template ultra-simplifié, exactement de quoi tomber amoureux… Si ce n'est qu'il est payant (entre 15 et 79€ selon l'utilisation).

Stacey

Stacey est très léger. PHP, 150 fichiers, 858 Ko. Template perso simple.

Pas de backend, et n'est plus maintenu depuis 2 ans, mais je voulais en parler juste pour montrer que parser du Markdown en un blog avec flux RSS, sitemap, pages statiques, cache, pagination, pouvait se faire en-dessous du mégaoctet.

Yellow

Yellow reste léger. PHP, 47 fichiers, 347 Ko. Template PHP.

Le projet a l'air prometteur, souvent mis à jour, bien qu'un peu limité au départ. De base, parse le Markdown pour en faire des pages, avec possibilité de les éditer directement depuis le site web (malheureusement, juste du texte, aucun support pour les images de ce côté-là). Assez nu, mais est disponible dans 12 langues et les plugins foisonnent (du flux RSS à l'intégration Youtube en passant par SmartyPants ou FontAwesome).

Simple, net, efficace, mais vraiment sec à l'utilisation.

Automad

Automad. PHP, 218 fichiers, 6,6 Mo. Template perso simple à utiliser mais incroyablement profond.

Cache, tags, sitemap, galerie, plugins. Et il y a un backend ultra-simple d'utilisation pour le client lambda (drag&drop des images, par exemple), ainsi que la possibilité d'avoir plusieurs utilisateurs ! Aurais-je trouvé ma perle rare ?

Peu de plugins pour le moment, pratiquement pas de communauté, par défaut les utilisateurs ont tous des droits d'admin. Bien qu'il soit plus complet et léger que Grav, sa taille relativement importante n'est toujours pas justifiée.
EDIT : On réalité, le contenu par défaut prend pas mal de place. Une fois mis à nu, Automad se rapproche plus des 3,9 Mo.

Parvula

Parvula ne semble pas fonctionner. PHP, 85 fichiers, 584 Ko. Template PHP. Enfin, quand je dis qu'il ne semble pas fonctionner, c'est qu'il faut modifier le .htaccess en changeant

RewriteRule ^(.*)$ index.php/$1 [L]

par

RewriteRule . index.php [L]

Ainsi, on évite les Page not found. L'administration est simple mais efficace, divisée en deux parties : à gauche l'éditeur Markdown, à droite son résultat WYSIWYG. Possibilité d'ajouter, de modifier ou de supprimer des pages, mais c'est tout. Vraiment dommage qu'il n'y ait rien pour les images. Ne semble pas gérer les sous-dossiers, donc difficile (mais pas impossible) d'en faire autre chose qu'un CMS pour site statique (et là-dessus, il bat Pico au niveau de la simplicité d'utilisation et de la légèreté). Néanmoins, aucun plugin, aucune communauté.

Oh, et sans pêcher par excès de chauvinisme, le développeur semble être français. À garder sous le coude pour de petits sites très simples.

Et tous les autres

Des CMS sans base de données, il en existe des paquets. J'en ai même codé un, fut un temps, c'est dire comme c'est simple à réaliser.

Ce comparatif n'est pas exhaustif, et n'a pas prétention à l'être. Parmi les outils que j'ai écarté, certains méritent une mention :

  • Nibbleblog est de qualité, très complet, on peut le voir comme le concurrent direct de PluXML ou de DotClear.
  • SiteCake est bien plus un générateur de site statique hébergé. Ça reste une solution simple à mettre en place et rapide à prendre en main par les clients.
  • Singularity tient dans un seul fichier PHP de 40 lignes. C'est minimaliste, mais intéressant.
  • Monstra est vraiment cool et peut remplacer assez simplement un GetSimple.
  • Baun. Après avoir vendu Pico à quelqu'un d'autre, l'auteur a décidé de recommencer un CMS léger sur le même principe, mais cette fois-ci en faisant payer le plugin d'administration (39 $)… PHP, 1300 fichiers, 3,7 Mo. Template Twig.
  • Et pour aller plus loin, l'utilisateur ahadb a dressé une petite liste des CMS flat-file.

Étude de cas

Prenons maintenant un exemple concret.

Pour un projet perso, j'ai un cahier des charges comme suit :

Thème simple HTML5 responsive support mobile

Pas de titre sur les billets

Pages statiques affichées comme un blog sans commentaires

2 utilisateurs différents, aucun des deux n'ayant accès au FTP ou au dépôt Git du serveur

2 styles différents selon l'auteur

2 modes de tri (ascendant/descendant par date)

trois possibilités d'écrire un article :

  • manuellement (Markdown) -> drag & drop ou éditeur
  • envoyer une photo -> drag & drop ou bouton classique
  • whiteboard -> écrire quelque chose au stylet qui est converti en image (vraiment optionnel)

Possibilité de se connecter en cliquant sur un lien Répondre

Syndication RSS/Atom

Donc, grosso modo, un Tumblr à deux collaborateurs. Ça parait bête comme chou, dit comme ça, non ?

  • PluXML peut faire ça, sans aucun problème, mais n'est pas assez simple au niveau de l'utilisation du backend.
  • GetSimple est pareil. Plus simple que PluXML, mais pas encore assez. À la limite, si on se débrouille avec le thème d'administration…
  • Grav demanderait de coder un plugin d'administration pour ça…
  • Dropplets ne supporte pas plus d'un utilisateur.
  • Phile nécessite de recoder un plugin d'administration…
  • Pico aurait besoin de lourdes modification sur le plugin d'administration.
  • Kirby est payant.
  • Stacey n'est plus vraiment maintenu et n'a pas d'administration.
  • Yellow aurait besoin de plus de modifications encore que Pico.
  • Automad irait parfaitement, si j'arrivais à trouver un moyen pour limiter les droits des utilisateurs, simplifier encore plus l'envoi des photos, et activer la syndication.
  • Parvula aurait besoin d'une bonne modification du backend.

On se retrouve donc avec des CMS qui font entre 1 et 2 Mo capables de réaliser ce que d'autres pesant entre 3 et 9 Mo sont incapables de produire. Le problème étant que les premiers ne sont pas aussi simples d'utilisation que les seconds.

Conclusion

Simple, les CMS file-based ? C'est mitigé. Ceux qui stockent leurs données en XML, plus anciens, semblent être bien plus complets et rapides à déployer, lorsque ceux basés sur du Markdown se concentrent sur la vitesse au détriment de fonctionnalités de base.

Si tout ce dont vous avez besoin, c'est d'un éditeur Markdown, quitte à devoir coder vos propres plugins, regardez du côté de Pico, Parvula et Automad.

Si au contraire vous avez besoin de fonctions « exotiques » telles qu'une barre de recherche, une syndication RSS, une pagination ou même le support des hébergements sans mod_rewrite, tournez-vous vers PluXML, Nibbleblog, GetSimple.

Maintenant, pour aller plus loin, il serait intéressant de jeter un œil aux divers scripts PHP qui, tenant en un seul fichier, permettent l'envoi de fichiers et leur gestion sur l'hébergement qui les accueillent. Je suis certain qu'en travaillant un peu là-dessus, on pourrait arriver à une interface d'administration flexible et portable d'un CMS à l'autre. Il ne manque qu'un dossier admin potable à Pico, Phile, Grav, Dropplets, Stacey, pour qu'on puisse réellement les considérer comme des CMS modernes. En somme, one backend to rules them all.

Note finale

Cet article a été écrit avec l'éditeur Markdown de Parvula, je n'ai eu qu'à récupérer le HTML généré pour le coller dans PluXML. Je pense l'adopter pour de petits projets, lui au moins il est léger…

Blink en CSS3

À l'époque d'HTML4, il y avait la balise <blink>. Elle n'était pas très populaire, au vu de sa sur-utilisation sur des sites bardés de gif de mauvais goût. Et aussi parce que, il faut l'avouer, un texte qui clignote, ça donne mal aux yeux.

Mais il arrive qu'on veuille tout de même recréer cet effet sous HTML5. Pour cela, rien de plus simple avec CSS3 !


.blink {
	animation-duration: 1s;
	animation-name: blink;
	animation-iteration-count: infinite;
	animation-timing-function: steps(2, start);
}

@keyframes blink {
	80% { visibility: hidden; }
}

On peut ainsi s'amuser à faire un prompt :

guillaume@yomli ~ $

Ou bien reproduire l'exemple de l'image :

Schroedinger's Cat

is NOT dead.

Chiffrer un message avec OpenPGP.js

Pour ma page de contact, je souhaitais faciliter l'envoi de messages chiffrés avec ma clé publique PGP. Dans l'idéal, une simple case à cocher permettrait de chiffrer le message avant l'envoi au serveur, puis de là dans ma boite mail. C'est pourquoi je me suis penché sur plusieurs implémentations d'OpenPGP en Javascript.

La première, Hanewinkel, était assez légère une fois minifiée (30 ko). Néanmoins, le chiffrement de messages contenant des caractères accentués posait problème. J'aurais pu m'en contenter, mais c'est toujours bon d'arriver à lire des messages directement. Si toutefois ça vous intéresse, voici un petit snippet à intégrer :


function encryptPGP(key, message){
	var pu = new getPublicKey(key);
 	if(pu.vers == -1) 
 		return;

	var keytyp = 0;      // 0=RSA, 1=Elgamal
	var keyid = pu.keyid;
	var pubkey = pu.pkey.replace(/\n/g,'');
	return doEncrypt(keyid, keytyp, pubkey, message);
}

$("#contact form").on("submit", function() {

	// Comme on va peut-être avoir besoin de
	// chiffrer le message, on n'utilise pas
	// le .serialize() habituel d'Ajax, mais
	// un tableau.
	var donnees = $(this).serializeArray();

	// Si la checkbox est cochée
	if($("#contact-crypted")[0].checked) {
		// On récupère la clé publique affichée
		// dans la page
		var key = $("#pgp-key").html();
		// On récupère le message
		var message = $("#contact-message").val();
		// On le chiffre
		message = encryptPGP(key, message);
		// Et on affiche le message chiffré
		$("#contact-message").val(message);

		// Enfin, on remplace le message par
		// son équivalent chiffré dans le tableau
		for(var i = 0; i < donnees.length; i++) {
			if(donnees[i].name == "contact-message")
				donnees[i].value = message;
		}
	}

	// On transforme notre tableau en une suite
	// de paramètres dont Ajax va se charger
	donnees = jQuery.param(donnees);

	// Et on envoie tout ça par Ajax pour
	// éviter un rechargement de la page
	$.ajax({
		url: $(this).attr("action"),
		type: $(this).attr("method"), 
		data: donnees,
		success: function(html) { 
			alert(html);
		},
		error: function(html) {
			alert(html);
		}
	});

    return false;
});

Je suis donc allé voir du côté d'openpgpjs, une solution plus lourde (250 ko), mais qui cette fois fonctionne avec les caractères accentués. Le problème principal qu'on a ici, c'est que openpgp est une promise. C'est cool pour un tas de choses, mais là on aimerait bien attendre la fin du chiffrement avant d'envoyer notre message au serveur. Oh, et au cas où vous vous le demanderiez, openpgp.js embarque un polyfill pour assurer la compatibilité avec les navigateurs qui ne tiennent pas leurs promesses…

Donc je passerai sur mes envies de meurtre lorsque j'ai compris que je devrais refaire tout le code et vous le présente tel quel :


$("#contact form").on("submit", function() {

	// Si la checkbox est cochée
	if($("#contact-crypted")[0].checked) {
		
		var contact = $("#contact form");
	
		// Comme on va peut-être avoir besoin de
		// chiffrer le message, on n'utilise pas
		// le .serialize() habituel d'Ajax, mais
		// un tableau.
		var donnees = $(contact).serializeArray();
	
		// On récupère le message
		var message = $("#contact-message").val();

		// On récupère la clé publique affichée
		// dans la page et on la prépare
		var pubkey = openpgp.key.readArmored($("#pgp-key").html());

		// Enfin, on lance le chiffrement
		openpgp.encryptMessage(pubkey.keys, message).then(function(pgpMessage){
			
			// On récupère le message chiffré
			message = pgpMessage;
			
			// Et on l'affiche
			$("#contact-message").val(message);

			// Enfin, on remplace le message par
			// son équivalent chiffré dans le tableau
			for(var i = 0; i < donnees.length; i++) {
				if(donnees[i].name == "contact-message")
				donnees[i].value = message;
			}

			// On transforme notre tableau en une suite
			// de paramètres dont Ajax va se charger
			donnees = jQuery.param(donnees);

			// Et on envoie tout ça par Ajax pour
			// éviter un rechargement de la page
			$.ajax({
				url: $(contact).attr("action"),
				type: $(contact).attr("method"), 
				data: donnees,
				success: function(html) { 
					alert(html);
				},
				error: function(html) {
					alert(html);
				}
			});
		}).catch(function(error){
			alert(error);
		});
	}
	// Et là la méthode classique,
	// sans chiffrement
	else {
		$.ajax({
			url: $(this).attr("action"),
			type: $(this).attr("method"), 
			data: $(this).serialize(),
			success: function(html) { 
				alert(html);
			},
			error: function(html) {
				alert(html);
			}
		});
	}	

	return false;
});

Note sur la sécurité : ne déployez pas cette solution autrement que pour un petit formulaire de contact. Il s'agit plus d'un proof of concept. J'entends par là qu'elle se base sur ce qu'on appelle dans le milieu host based security, autrement dit aucune véritable sécurité. Il suffit à quelqu'un (que ce soit l'hébergeur, le FAI, le VPN, le navigateur, etc.) de changer la clé publique, le fichier openpgp.js ou le code javascript pour qu'il soit capable de lire le message. Plus d'informations sur cet article.


À propos de ce blog

Certains ont des carnets de notes, les développeurs web ont tendance à avoir des blogs. Ça leur permet de partager leurs découvertes, de garder une trace de leurs hacks beaucoup plus simplement. Voici le mien.

Vous trouverez ici pas mal de trucs de geek, principalement des bouts de code en développement web, mais également quelques scripts bash pour faciliter l'utilisation quotidienne de GNU/Linux (je tourne sous Linux Mint 17.1 actuellement). La catégorie Veille comporte quelques articles d'actualité, mais rien de bien folichon.

Si l'envie vous prend de me contacter, vous trouverez toutes les informations utiles dans le footer (le bas de page, pour les burnes en anglais), ou bien vous pouvez utiliser la page de contact dédiée.

Enfin, si vous trouvez ici des informations utiles, n'hésitez pas à m'offrir un café en cliquant sur le bouton :

Offrir un café  
-----BEGIN GEEK CODE BLOCK-----
  Version: 3.20
  GCS dx s:- a- c+ C++ B+++ 7-- w E- O- L++ M- u++ W+++$ 
  H++++ Z+++ F--- PS+++ PE-- Y+ PGP++ T++ S J+++ t@ X- 
  R+++ m+ !tv b+++@ DI? D++ G e* h+ A- r y++
------END GEEK CODE BLOCK------
					
Haut de page