Parce que ce n'est pas aussi simple que ça en a l'air.
C'est pas la vue qui devrait se charger de ce genre de choses ?
Si.
et le moteur de template le fait pas automatiquement ?
Si, aussi.
Mais la tribune est un cas particulier, les messages qui y sont postés sont poussés aux navigateurs via une technique de long-polling en passant par un daemon intermédiaire (Board). Du coup, pour éviter d'avoir à échapper deux fois les mêmes champs (une fois pour l'affichage normal et une fois pour le rafraichissement automatique en JS), je préfère faire ça en amont.
C'est un choix discutable mais, pour le moment, je privilégie la non-duplication du code à la pureté idéologique.
h est une méthode fournie par Ruby on Rails qui sert à échapper un contenu HTML. Il remplace <, > et & par les entités HTML correspondantes, ce qui évite les attaques XSS.
The HttpOnly attribute limits the scope of the cookie to HTTP
requests. In particular, the attribute instructs the user agent to
omit the cookie when providing access to cookies via "non-HTTP" APIs
(such as a web browser API that exposes cookies to scripts).
Je viens de relire la RFC sur ATOM et, sauf erreur de ma part, akregator ne devrait pas interpréter le HTML (et donc afficher l'image) pour l'élément author. Je t'encourage à remonter ce problème aux auteurs d'akregator.
Et pour "Sur 1469 comptes utilisateur valides et utilisés au cours des 3 derniers mois :", c'est au moins divisé par 2 par rapport à ceux qui se logguaient auparavant
Il ne faut pas toujours croire ce que dit ce genre de rapport ;-)
Il faudrait un img.linuxfr.org par exemple pour pouvoir accélérer les "Parallelize downloads" (téléchargements en parallèle ?)
Déjà, il ne faudrait pas qu'un seul sous-domaine mais plusieurs, sinon on ne parallélise rien du tout. Mais surtout, avec les navigateurs modernes, le gain est à peu près nul : ce que l'on gagne en ouvrant plus de connexions, on le perd à faire des résolutions DNS supplémentaires. Et en HTTPS, c'est carrément contre-productif à cause du coût d'ouverture des sessions SSL. Par exemple, github a fait le chemin inverse (ils ont toujours un sous-domaine parce qu'ils utilisent un CDN, chose que LinuxFr.org n'a pas les moyens de s'offrir).
Imposer la taille des images, pour que les navigateurs n'aient pas à les calculer
Je vais regarder mais ce n'est pas aussi simple que cela en a l'air.
La chaîne à la fin de chaque ressource statique ("?8ee4320" par exemple) empêche le contenu d'être correctement mis en cache.
Oui et non. La réalité est bien plus compliquée que ça. Il y a différents types de mises en cache (etags vs date d'expiration). Dans notre cas, la chaîne est là pour forcer les navigateurs à venir chercher une nouvelle version quand un fichier a été modifié. Ensuite, le navigateur va pouvoir utiliser cette ressource depuis son cache sans avoir à faire de requête HTTP vers le serveur pendant un bon bout de temps.
Si j'enlève la chaîne, les navigateurs vont mieux cacher la ressource, à tel point qu'ils continueront d'utiliser l'ancienne version même quand une nouvelle version sera déployée. Pour éviter les nombreux bugs qui s'en suivraient, il faudrait alors demander aux navigateurs de revalider chaque ressource à chaque utilisation, ce qui rendrait quasiment inutile l'utilisation du cache pour la majorité des ressources de LinuxFr.org (on a beaucoup de petits fichiers).
=> Je garde la solution actuelle même si ça donne une note moindre à LinuxFr.org dans les rapports de performances.
config.serve_static_assets = true
Non, rien à voir. Cette ligne sert à indiquer au serveur applicatif de servir les fichiers statiques. Nous n'en avons pas besoin car Nginx sert les fichiers statiques en production.
La classique optimisation des png
Déjà faite ;-)
Le rapport donne une mauvaise note à cause de la bannière qui provient de La Quadrature Du Net. Je n'ai pas la main pour optimiser ça.
Je ne suis pas d'accord avec l'outil. Le fichier CSS en question n'est pas si petit que ça et il se trouve sur toutes les pages donc autant l'avoir en cache.
Les AMR passent régulièrement sur l'espace de rédaction pour faire le ménage, et au pire, son auteur peut la soumettre à la modération. Ce n'est donc pas utile d'avoir un bouton en plus pour la supprimer.
[^] # Re: Ruby pour les nuls
Posté par Bruno Michel (site web personnel) . En réponse au journal XSS. Évalué à 3.
Oui.
Parce que ce n'est pas aussi simple que ça en a l'air.
Si.
Si, aussi.
Mais la tribune est un cas particulier, les messages qui y sont postés sont poussés aux navigateurs via une technique de long-polling en passant par un daemon intermédiaire (
Board
). Du coup, pour éviter d'avoir à échapper deux fois les mêmes champs (une fois pour l'affichage normal et une fois pour le rafraichissement automatique en JS), je préfère faire ça en amont.C'est un choix discutable mais, pour le moment, je privilégie la non-duplication du code à la pureté idéologique.
[^] # Re: Ça serait pas arrivé avec django...
Posté par Bruno Michel (site web personnel) . En réponse au journal XSS. Évalué à 10.
Rails 3 a aussi de l'échappement automatique. Il n'empêche qu'il arrive parfois que l'on contourne ça pour de bonnes raisons (ou des mauvaises).
Ici, le problème était de ma faute et aurait eu lieu aussi bien avec Django qu'avec Rails.
Ha, ils ont abandonné Python ?
[^] # Re: Ruby pour les nuls
Posté par Bruno Michel (site web personnel) . En réponse au journal XSS. Évalué à 3.
h
est une méthode fournie par Ruby on Rails qui sert à échapper un contenu HTML. Il remplace <, > et & par les entités HTML correspondantes, ce qui évite les attaques XSS.[^] # Re: ça c'est la classe
Posté par Bruno Michel (site web personnel) . En réponse au journal XSS. Évalué à 3.
Va sur http://linuxfr.org/compte/modifier et coche la case « Ne pas afficher les avatars » :p
[^] # Re: explications ?
Posté par Bruno Michel (site web personnel) . En réponse au journal XSS. Évalué à 5.
Il y a besoin de rentrer le mot de passe actuel pour le changer, le cookie ne suffit pas. Par contre, tu peux effectivement poster sur la tribune.
[^] # Re: explications ?
Posté par Bruno Michel (site web personnel) . En réponse au journal XSS. Évalué à 4.
Ça ne va pas marcher pour les cookies de LinuxFr.org qui sont en HttpOnly et ne dont donc pas accessibles avec du javascript.
Pour rappel, http://tools.ietf.org/html/draft-ietf-httpstate-cookie-21#section-4.1.2.6 indique :
[^] # Re: Nouvelle faille? cette fois dans le RSS
Posté par Bruno Michel (site web personnel) . En réponse au journal XSS. Évalué à 7.
Je viens de relire la RFC sur ATOM et, sauf erreur de ma part, akregator ne devrait pas interpréter le HTML (et donc afficher l'image) pour l'élément
author
. Je t'encourage à remonter ce problème aux auteurs d'akregator.[^] # Re: Adresse IP
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi bug sur le sondage, on le demande plus d'une fois . Évalué à 2 (+0/-0).
Le but est justement de permettre à tous les visiteurs de voter, qu'ils aient un compte ou non.
[^] # Re: explications ?
Posté par Bruno Michel (site web personnel) . En réponse au journal XSS. Évalué à 2.
Tu ne peux pas récupérer simplement les cookies avec un javascript. Ils sont en
httpOnly
.# Suivi
Posté par Bruno Michel (site web personnel) . En réponse au journal XSS. Évalué à 9.
Pour info, il y a également une entrée de suivi sur le sujet : http://linuxfr.org/suivi/petit-probleme-daffichage-du-login-dans-la-tribune et la faille en question vient d'être corrigée avec https://github.com/nono/linuxfr.org/commit/3ba7867634a29723771d8f1c6e5e5017e4fde9c8
[^] # Re: ça c'est la classe
Posté par Bruno Michel (site web personnel) . En réponse au journal XSS. Évalué à 10.
Trop tard, c'est déjà corrigé.
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi petit probleme d'affichage du login dans la tribune. Évalué à 2 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/3ba7867634a29723771d8f1c6e5e5017e4fde9c8
[^] # Re: Statistiques non encore recodées
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Statistiques à recoder. Évalué à 2 (+0/-0).
Corrigé avec https://github.com/nono/linuxfr.org/commit/f2e16c9b37c263858d7a6325e031d9c42c9821ad
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Le site détecte une erreur quand on arrive sur une page inexistante du wiki. Évalué à 2 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/c012cd013d6beae6fb970a11962b95cc2b86d935
[^] # Re: Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Autoriser la suppression des ses tags. Évalué à 2 (+0/-0).
Il faut activer les images.
# Doublon
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi 404 sur les statistiques sur les contenus. Évalué à 2 (+0/-0).
En fait, la page n'a pas encore été codée. Cf http://linuxfr.org/suivi/statistiques-%C3%A0-recoder
# Doublon
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Édition des contenus postés. Évalué à 2 (+0/-0).
Cf http://linuxfr.org/suivi/fonction-d%C3%A9dition-des-textes-commentaires-journaux-etc
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Barre d'outil et Une en page d'accueil. Évalué à 2 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/27a9e4f7e00dbc431932add559048f56539519a8
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Ajouter une colonne modifier vide dans le tableau du suivi. Évalué à 2 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/3b7c408a3053f4776f5c5a3d77f02ced0f1d5f13
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Inclure mes réponse et le tableau sur la même ligne. Évalué à 2 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/3b7c408a3053f4776f5c5a3d77f02ced0f1d5f13
# Ou pas
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Optimisations. Évalué à 5 (+0/-0).
Il ne faut pas toujours croire ce que dit ce genre de rapport ;-)
Déjà, il ne faudrait pas qu'un seul sous-domaine mais plusieurs, sinon on ne parallélise rien du tout. Mais surtout, avec les navigateurs modernes, le gain est à peu près nul : ce que l'on gagne en ouvrant plus de connexions, on le perd à faire des résolutions DNS supplémentaires. Et en HTTPS, c'est carrément contre-productif à cause du coût d'ouverture des sessions SSL. Par exemple, github a fait le chemin inverse (ils ont toujours un sous-domaine parce qu'ils utilisent un CDN, chose que LinuxFr.org n'a pas les moyens de s'offrir).
Je vais regarder mais ce n'est pas aussi simple que cela en a l'air.
Oui et non. La réalité est bien plus compliquée que ça. Il y a différents types de mises en cache (etags vs date d'expiration). Dans notre cas, la chaîne est là pour forcer les navigateurs à venir chercher une nouvelle version quand un fichier a été modifié. Ensuite, le navigateur va pouvoir utiliser cette ressource depuis son cache sans avoir à faire de requête HTTP vers le serveur pendant un bon bout de temps.
Si j'enlève la chaîne, les navigateurs vont mieux cacher la ressource, à tel point qu'ils continueront d'utiliser l'ancienne version même quand une nouvelle version sera déployée. Pour éviter les nombreux bugs qui s'en suivraient, il faudrait alors demander aux navigateurs de revalider chaque ressource à chaque utilisation, ce qui rendrait quasiment inutile l'utilisation du cache pour la majorité des ressources de LinuxFr.org (on a beaucoup de petits fichiers).
=> Je garde la solution actuelle même si ça donne une note moindre à LinuxFr.org dans les rapports de performances.
Non, rien à voir. Cette ligne sert à indiquer au serveur applicatif de servir les fichiers statiques. Nous n'en avons pas besoin car Nginx sert les fichiers statiques en production.
Déjà faite ;-)
Le rapport donne une mauvaise note à cause de la bannière qui provient de La Quadrature Du Net. Je n'ai pas la main pour optimiser ça.
Pour les sprites CSS, il y a déjà une entrée ouverte : http://linuxfr.org/suivi/utiliser-loutil-de-google-pour-acc%C3%A9l%C3%A9rer-le-site-web#comment-1223067
Je ne suis pas d'accord avec l'outil. Le fichier CSS en question n'est pas si petit que ça et il se trouve sur toutes les pages donc autant l'avoir en cache.
Là, j'avoue, je ne suis pas un spécialiste des CSS, il y a sûrement pas mal de choses à faire :p
# Doublon
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi L'échappement des ^ ne fonctionne pas. Évalué à 2 (+0/-0).
Cf http://linuxfr.org/suivi/echapement-de-caract%C3%A8res
# Pas utile
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Manque la suppression d'une dépêche en rédaction. Évalué à 2 (+0/-0).
Les AMR passent régulièrement sur l'espace de rédaction pour faire le ménage, et au pire, son auteur peut la soumettre à la modération. Ce n'est donc pas utile d'avoir un bouton en plus pour la supprimer.
# Nope
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Gestion des licences de contenu, préférences. Évalué à 2 (+0/-0).
Ça n'a pas l'air d'intéresser grand monde => je ferme.
# Doublon
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Petit écran. Évalué à 2 (+0/-0).
Cf http://linuxfr.org/suivi/url-sp%C3%A9ciale-petits-%C3%A9cran