Adrien Dorsaz a écrit 958 commentaires

Pour cette série, je viens de proposer un PR qui remanie pas mal le layout pour le passer à nouveau à 2 colonnes:

Après plusieurs essais de design avec @mjourdan pour la réorganisation de l'espace de rédaction (voir les discussions dans le PR #242), le résultat est le suivant:

• Le layout est de nouveau sur 2 colonnes
• La colonne de droite est un panneau qui prend tout l'espace vertical et qui peut être caché.
• Quand le panneau de droite (#toolpanel) est affiché, la zone de rédaction est légèrement réduite
• La barre d'outil a été ajoutée dans ce layout (#toolbar) et, contrairement aux autres pages, elle ne contient que 2 bouttons sur la droite: un pour afficher/cacher le panneau de droite et un second pour afficher / cacher un sommaire
• Pour gérer le fait d'afficher / cacher des portions de la page, un nouvel outil JavaScript popup a été crée.
  • Ce système est réutilisable pour d'autres parties de l'espace de rédaction. Par contre, je le déconseillerai sur le reste du site, car ça rend JS indispensable (ce qui est déjà le cas pour l'espace de rédaction)
  • Lors d'un clique:
  • Le JavaScript lit l'attribut data-popup-id de l'objet cliqué.
  • Cet identifiant doit correspondre à un id d'un élément de la page. Le JS retrouve cet élément et lui ajoute (ou retire) l'attribut data-popup-shown
  • Comme plusieurs éléments peuvent déclencher ce JS, le JS retrouve tous les déclencheurs qui ont l'attribut data-popup-event-#{id retrouvé plus haut}
  • Enfin, il est possible d'ajouter également des listeners qui souhaitent "écouter" les changements d'état d'un élément. Dans l'élément à afficher/cacher, il faut ajouter l'attribut data-popup-listner-ids avec une liste d'identifant séparé par des espaces.
  • Le JS ne gère que les attributs des éléments du DOM. Tout ce qui est affichage et transitions est géré directement par CSS (à créer à la main selon les besoins).

D'après mes tests, ce code est compatible jusqu'à IE 10, je n'ai pas essayé de navigateurs plus vieux. Si vous voulez tester, ce code est actuellement installé sur https://dlfp.adorsaz.ch (utilisateur: moderateur, mot de passe identique).

PS: Je n'ai pas le courage de faire le ménage dans les commits, on y voit donc tout l'historique de rechreche de design… Est-ce que vous voulez que je fasse un squash avec toutes les modifications ? Ça ferait un gros commit, mais ça éviterait de polluer l'historique git…

Pour l'instant, je me limite au navigateur Internet Explorer 10 (sorti en 2012). Il permet de faire déjà pas mal de choses et il a quand même déjà 7 ans :)

Merci, ça semble bien fonctionner :-)

Ahaha, je me suis trompé, le cache est activé pour 86400*0* secondes et donc 10 jours, pas juste 1 :-)

Je me suis rendu compte quand j'ai préparé un PR qui active le mimetype pour woff2 et le cache pour ces polices:

https://github.com/linuxfrorg/admin-linuxfr.org/pull/5

J'ai fais ces modifications à la main et je ne les ai pas testées, alors il pourrait y avoir une erreur qui s'y est glissée…

Bon en vrai, la branch master de ce dépôt git n'a pas bougé depuis 2017, c'est peut être pas le bon endroit.

Hello,

Si je ne me trompe pas, c'est la configuration du serveur nginx qu'il faudrait ajuster.

J'ai regardé le contenu du dossier /public/fonts et je dirai qu'il faudrait activer le cache du navigateur pour tous les fichiers présents (les extensions y présentes sont pour l'instant afm, otf, ttf, woff, woff2).

Voici les résultats avec curl et différents fichiers (on voit bien que cache-control est présent pour une image et pour une police ttf, mais pas pour les nouvelles en woff et woff2):

adrien@bureau-ado ~/code/linuxfr.org/public/fonts
 % curl -I https://linuxfr.org/images/markdown.png
HTTP/2 200 
server: nginx/1.10.3
date: Thu, 19 Sep 2019 18:35:12 GMT
content-type: image/png
content-length: 298
last-modified: Sat, 24 Feb 2018 14:16:08 GMT
etag: "5a9173a8-12a"
expires: Sun, 29 Sep 2019 18:35:12 GMT
cache-control: max-age=864000
x-content-type-options: nosniff
accept-ranges: bytes

adrien@bureau-ado ~/code/linuxfr.org/public/fonts
 % curl -I https://linuxfr.org/fonts/LinLibertine.ttf 
HTTP/2 200 
server: nginx/1.10.3
date: Thu, 19 Sep 2019 18:36:20 GMT
content-type: font/truetype
content-length: 509248
last-modified: Wed, 13 Jul 2011 12:40:26 GMT
etag: "4e1d923a-7c540"
expires: Sun, 29 Sep 2019 18:36:20 GMT
cache-control: max-age=864000
x-content-type-options: nosniff
accept-ranges: bytes

adrien@bureau-ado ~/code/linuxfr.org/public/fonts
 % curl -I https://linuxfr.org/fonts/Lato-Regular.woff
HTTP/2 200 
server: nginx/1.10.3
date: Thu, 19 Sep 2019 18:35:37 GMT
content-type: application/font-woff
content-length: 309192
last-modified: Sat, 24 Aug 2019 20:47:48 GMT
etag: "5d61a274-4b7c8"
x-content-type-options: nosniff
accept-ranges: bytes

adrien@bureau-ado ~/code/linuxfr.org/public/fonts
 % curl -I https://linuxfr.org/fonts/Lato-Regular.woff2
HTTP/2 200 
server: nginx/1.10.3
date: Thu, 19 Sep 2019 18:36:26 GMT
content-type: application/octet-stream
content-length: 182708
last-modified: Sat, 24 Aug 2019 20:47:48 GMT
etag: "5d61a274-2c9b4"
x-content-type-options: nosniff
accept-ranges: bytes

Je suis étonné que l'on ait mis que 86400 secondes, ça fait juste un jour de cache. Personnellement, surtout pour les polices, j'aurais mis quelque chose comme 1 semaine, car c'est vraiment rare de les changer.

Hello,

J'ai regardé un peu le code et il me semble que pour l'instant LinuxFr ne permet pas de retrouver des informations des autres utilisateurs.

C'est bien les avatars de tous les correspondants dont tu aurais besoin ?

Si oui, il faudrait faire une api du style users/{id or name}. Est-ce envisageable par les administrateurs ?

Comme tous les avatars ne sont pas stockés sur LonuxFr, je pense que seule l'API pourra te donnerles bonnes URLs.

PS: je n'ai pas réussi à utiliser l'API avec Insomnia. Je n'ai pas bien compris l'oauth2 je crois… Si tu pouvais me guider je pourrai tester plus facilement :-)

Je pense qu'on s'est tous fait "bousculer" un jour dans les commentaires […], suffit d'aller faire un tour, boire un verre d'eau, et réaliser qu'aussi passionantes soient les discussions sur DLFP ça reste essentiellement du hobby.

Je pense que tu soulèves un point très important et pas toujours facile à appliquer quand les sentiments sont à vif.

Il faut clairement apprendre à prendre du recul par rapports aux commentaires des autres sur Internet (et aussi par rapport aux systèmes de notation).

Un problème est que les silos à publicité comme les réseaux sociaux font leur beurre sur le fait de nous faire réagir très vite et de manière inconsidérée : ça leur fait plus de contenu, plus de pages affichées (et donc de pub) et plus de revenu au final.

Du coup ils forcent les gens à ne plus prendre de recul et quand ils arrivent ici, les utilisateurs ont l'impression que le karma est le point essentiel de LinuxFr.

Alors que non, bien au contraire: pour moi, LinuxFr n'est pas un réseau sociale, mais un site de partage d'informations (l'espace de rédaction collaborative est vachement bien fait !) et d'entre-aide.

L'essentiel est donc dans le contenu, pas dans le jugement des autres via le système de karma (par contre le contenu des commentaires fait parti du contenu créé par la communauté).

Bon, si j'ai bien compris tes commentaires, ce correctif devrait rendre plus lisible le site:
https://github.com/linuxfrorg/linuxfr.org/pull/248

Je me réjouis de voir un nouveau journal pour m'expliquer que les polices sont devenus trop énorme :D

Je ne te trouve pas assez ambitieux: l'user agent devrait faire lui-même les CSS pour tous les sites.

Oui, j'ai vu ce matin, ma question pour Zenitram et arnaudus est: est-ce que c'est bien de ce changement que tu parles ?

Si c'est ça, j'arrive à reproduire et je pourrais faire un correctif :-)

Est-ce que tu peux répondre à ce commentaire stp ?

Je n'avais pas vu la différence quand j'ai changé la police. Il semble bien que le rendu est un peu plus petit et du coup que les interlignes semblent plus grand.

Comme ça je peux voir si Zenitram et toi, vous parlez du même problème.

Dis-moi, le soucis de taille, est-ce que tu le vois dans cette comparaison (après / avant):

Si c'est bien de ce genre de changement que tu parles, je ne l'avais pas vu effectivement (même quand j'ai fait cette capture d'écran).

Si non, je ne suis vraiment pas capable de reproduire ton problème.

L'idéal serait de proposer le nouveau design d'un coup, oui.

Mais je n'ai pas le temps ni la motivation ni les moyens de tout faire. Même si c'était possible pour moi, ce n'est pas forcément le cas pour mjourdan et Bruno Michel.

On a déjà fait des tests pour l'espace de rédaction et c'est vite énorme les changements à mettre en place: https://github.com/linuxfrorg/linuxfr.org/pull/242

Pour moi, c'est beaucoup plus rassurant de casser ce bloc de modifications en plus petit morceaux. C'est plus facile à repérer les problèmes (autant système qu'utilisateur).

D'ailleurs, je n'ai qu'un écran avec densité de pixel non-élevée. Je ne peux donc ni reproduire ni corriger ce genre de bug.

Par contre la solution de PsychoFox me semble très pertinente :-)

Hier, j'avais oublié de mettre les polices alternatives système serif et sans-serif.

Du coup, quand on bloquait les polices web, tout le site était en serif.

C'est donc possible qu'il y aie eu des rendus avec des polices à empattement uniquement.

De rien, c'est amusant de bidouiller le code :-)

Merci à Bruno également pour les mises en production rapides !

J'avais oublié en effet de définir la police comme "cherche d'abord sur le disque, si non télécharge".

C'est corrigé.

Remarquez que la police n'est pas téléchargée à chaque chargement de page: le navigateur la garde en cache. Donc les 250 Kio et 0.5ms d'attentes, c'est 1 fois ;-)

Enfin, j'ai aussi ajouté les alternatives système (serif et sans-serif). On devrait être au top maintenant.

Oups, je me suis trompé dans tout le texte:

s/Lota/Lato/

désolé :)

Ton analyse est tout juste :-)

J'avais essayé avec "Lota Regular", pour avoir une idée, regardez le commentaire plus bas.

Hello,

J'essaie par petits pas de faire passer LinuxFr au nouveau design proposé par mjourdan, il y a déjà quelques temps.

Pour aller par petits pas, je voulais déjà changer les polices, car c'est déjà faisable avec le design actuel. J'ai bien aimé l'idée d'utiliser une police à empattement pour les titres et une police sans empattement pour les contenus.

Tu vois donc déjà, que, tout le site n'est pas à empattement au contraire de ce que pourrais faire penser ton journal. Ce que j'aime bien avec la police à empattement, c'est que le rendu permet de se passer du gras pour les titres, car la police et la taille les distingue bien du contenu.

Maintenant, c'est vrai que j'ai eu un doute quand j'ai installé la police "Lato Light" au lieu de "Lato". Le rendu tel que vous le voyez maintenant, est bien celui prévu (la couleur de la police est bien noir, mais la police est plus fine.

Lato Light	Lato

(Cliquez sur les images pour les télécharger)

Je trouve que Lato (Light ou non) est déjà plus lisible que la police "Sans" précédente, je distingue mieux les lettres personnellement.

En regardant ces 2 rendus, je trouve que les boutons et menus sont mieux avec "Lato Light" (surtout pour le pied de page). Je voulais donc proposer une solution ou on garde "Lato Light" pour le site en général, mais que l'on utilise "Lato" pour les contenus.

Tiens, tout ça mériterait un sondage pour avoir un avis globale :-)

PS: Pour tester en live ce que ça donne avec "Lato", il vous faut ouvrir la console web et remplacer "Lato Light" par "Lato" dans le style CSS.

Ça marche aussi avec les domaines dynamique du style dyndns ?

Je ne sais pas, je n'utilise pas ce genre de service. Je te laisse chercher.

Si la machine qui demande le certificat est sur un réseau A et le serveur DNS sur un réseau B qui gère le domaine (les deux étant relié par une liaison quelconque), ça peut fonctionner ?

Tant que ta machine sur le réseau A peut donner un ordre de mise à jour DNS au serveur le réseau B, oui.

L'autre condition est que la machine du réseau A puisse envoyer des requêtes HTTPS sur Internet pour communiquer avec le serveur ACME.

Non, mais tu a annoncés:

1. "J'utilise VPN pour connecter mes machines en direct"
2. "Je n'ai pas besoin d'HTTPS sur mes machines grâce à VPN"
3. "Je maîtrise l'utilisation de TLS, SSH, …"

Du coup, excuse-moi, mais j'en ai déduit effectivement que tu utilisais SSH entre tes machines.

Mais c'est vrai que tu ne l'as pas dit. Donc peut-être que tu maîtrises tellement ton VPN que tu utilises directement telnet entre tes machines. Ce serait au moins cohérent avec les autres phrases du style "il y a des risques de sécuriser les communications dans un tunnel sécurisé".

Franchement, je vais m'arrêter sur ce sujet tant que tu ne structures pas plus ce que tu nous dis et que tu places des phrases du genre "Pour un site censé être peuplé de gens callés, c'est fort kikoolol.". Ça m'attriste et, maintenant, j'ai même un peu peur du contenu existant dans le wiki de LinuxFr.

Ok, je vois, mais stp, arrête de dire que Let's Encrypt ne sait utiliser que du port 80 ou 443: c'est tout bonnement faux.

De souvenir quand tu utilises un port non standard, alors ce port est inséré dans le nom de domaine (par exemple HelloWorld.com:8666 et le certif n'est alors pas utilisable sans alerte pour HelloWorld.com).

Pour le challenge HTTP ("montre moi que tu peux poser un fichier sur un serveur web accessible avec ce domaine"), oui, c'est bien le port 80 qui est requis et ce simplement pour prouver que tu maîtrises l'infrastructure Web du nom de domaine.

Tu peux utiliser le challenge DNS ("montre moi que tu peux créer une ressource DNS pour ce domaine"), eh bien, c'est le port 53 qui est utilisé.

Pour l'instant, ces 2 challenges sont les seuls disponibles et donc les ports 53 et 80.

Si tu veux pouvoir créer des certificats tu dois donc nécessairement avoir un de ces 2 ports accessibles sur Internet, si non, ça veut dire que tu n'es pas capable de prouver que ces domaines t'appartiennent.

Serait-ce utilisable pour jean-kévin qui voudrait sécuriser l'accès à la WEBUI de sa seedbox Deluge ?

Je ne sais pas ce qu'est une seedbox Deluge, mais si tu es capable d'y associer un nom de domaine oui, tu peux la sécuriser par une des 2 techniques proposées par le protocole ACME.

Mon outil, acme-dns-tiny, par exemple nécessite une machine avec un service DNS qui est capable de faire de la mise à jour dynamique des ressources DNS grâce à TSIG. Sur une autre machine (ta seedbox par exemple), tu as juste besoin d'avoir python3 (avec les modules dnspython et requests) et openssl d'installé. Tu peux voir la documentation pour configurer ta seedbox et le serveur avec bind9 dans le wiki.

Cet outil, n'est pas le seul à savoir faire des certificats avec le challenge DNS, je te laisse chercher sur le web celui qui te convient le mieux.

---

Pour la partie certificats auto-signés, je vois donc que ce n'est pas facilement cassable si tu sais gérer les certificats installés sur tes machines (donc en les pré-installant sur les machines concernées pour ne pas avoir à faire des comportements dangereux comme "accepter par défaut tous les certificats auto-signés"). Et comme ce serait pour utiliser dans un réseau local, ça devrait le faire assez facilement et donc l'excuse "j'utilise un VPN" n'est pas du tout un bon argument.

Note d'ailleurs que SSH a exactement le même défaut si tu n'installes pas les clés de l'hôte dans des ressources DNS sécurisées par DNSSEC: tu dois manuellement vérifier les fingerprint des certificats utilisé par SSH.

Ok, je vois, mais stp, arrête de dire que Let's Encrypt ne sait utiliser que du port 80 ou 443: c'est tout bonnement faux. D'ailleurs avec le challenge DNS, Let's Encrypt n'a même pas besoin d'accéder à tes machines autres que celles qui gèrent tpn service DNS.

Perso, même si c'est pour du réseau "local", je ne ferais quand même rien passer en claire, car tu ne peux jamais être sûr de la santé des machines connectées au réseau.

J'ai voulu confirmer cette affirmation avec Stack Overflow et la réponse rappelle d'ailleurs qu'ARP est facilement cassé et donc qu'une machine malveillante peut "piquer" ton IP.

J'ai vu sur StackOverflow également que tu peux faire des certificats autos signés pour des adresses IP.

Pourquoi dis tu que les communications avec certificats auto-signé sont facilement cassées ? Est-ce aussi simple que l'ARP spoofing ?

Enfin, depuis le début, on parle de Chrome et de Firefox pour la désactivation d'HTTPS: ce sont des outils destinés au grand publique et je comprend bien qu'ils se sentent obligés et responsables d'activer le HTTPS partout. Surtout avec les possibilités offertes par ACME. Maintenant tu nous parles de curl, qui lui, clairement est un outil de technicien et aurait très peu de raisons de désactiver HTTP.
As tu vraiment besoin de Firefox ou Chrome dans ta situation qui n'est pas "grand publique" ?

J'ai l'impression que tout ces cas de figures sont mélangés dans tes commentaires et que c'est pour ça que l'on a de la peine à s'entendre…

Pour Let's Encrrypt, il faudrait arrêter de dire qu'ils ne veulent que communiquer sur le port 80 et 443. C'est un des différents moyens d'automatiser la gestion des certificats.

Un des autres moyens que je pense assez bien connaitre est l'automatisation par la preuve de gestion de resources DNS. C'est hyper utile pour gérer ses serveurs, entre autre grâce à la mise à jour dynamique des resources DNS bien gérée par bind9 (entre autre, je ne connais pas les autres) et l'utilisation des CNAME.

J'entend bien l'argument de la flemme pour mettre en place HTTPS, mais je t'avouerai que ça me ferait poser de sacré doutes sur la gestion de la sécurité du chiffrement de tes autres services comme le VPN.

En plus, si tu te plante sur la config du VPN ou des plages IPs autorisées, le trafique réseau passe alors en claire et ca c'est un risque réel et pas "potentiel".