On affiche déjà un message de confirmation à l'inscription. Il apparaît en haut de la page dans un cadre rose et il dit « Vous vous êtes inscrit avec succès. Vous allez recevoir les instructions de confirmation par courriel ».
Les boutons de partage sont utilisés pour créer des liens vers les articles et les partager sur les réseaux sociaux. Au contraire, sur LinuxFr.org, nous encourageons l'écriture de contenus propres au site et évitons de reprendre tel quel des contenus tierces, ou même juste un lien vers ceux-ci. Donc, je ne pense pas qu'un bouton de partage pour LinuxFr.org ait beaucoup d'intérêt. D'ailleurs, pas grand monde s'est manifesté dans les commentaires pour aller dans ce sens. Du coup, je ferme cette entrée de suivi.
EDIT : mais c'est surtout que je trouve que linuxfr.org devrait nous rediriger automatiquement vers la page chiffrée, qu'est-ce que vous en pensez ?
Si un utilisateur va sur la page en https et s'authentifie, on dépose un cookie pour faire la redirection automatique de http vers https (et le cookie d'authentification est envoyé en https uniquement). Par contre, nous ne souhaitons pas étendre ce mode de fonctionnement aux autres utilisateurs car il peut y avoir de bonnes raisons de ne pas pouvoir accéder au https (proxys d'entreprises qui refusent notre certificat par exemple).
Bon, j'ai un brouillon de patch qui Devrait Marcher. Me reste plus qu'à trouver comment tester.
Pour tester, tu lances img, puis tu fais ça dans un terminal :
# On stocke dans redis l'URL pour l'autoriser$ redis-cli hsetnx 'img/http://linuxfr.org/images/logos/logo-linuxfr-automne.png' created_at 1
# On encode en hexadécimal l'URL$ irb
> 'http://linuxfr.org/images/logos/logo-linuxfr-automne.png'.unpack('H*')=> ["687474703a2f2f6c696e757866722e6f72672f696d616765732f6c6f676f732f6c6f676f2d6c696e757866722d6175746f6d6e652e706e67"]# Puis, on fait une requête dessus avec curl ou wget$ wget http://127.0.0.1:8000/img/687474703a2f2f6c696e757866722e6f72672f696d616765732f6c6f676f732f6c6f676f2d6c696e757866722d6175746f6d6e652e706e67/logo.png
Par contre j'ai bien l'impression que ce serveur de cache est sujet à des conditions de course.
Oui, je m'étais déjà dit ça. Si je me souviens bien, le problème était l'absence de synchronisation entre le moment où l'on écrit le fichier sur le disque et les appels à redis. On pourrait effectivement se retrouver avec un mauvais Content-Type dans ce cas.
En pratique, ça m'avait l'air hautement improbable que ça se produise et, au pire, pas très compliqué à nettoyer à la main. Donc, j'ai du me dire que je verrais ça un autre jour ;-)
Le "raisonnable" dépend des cas. Ça peut être une valeur arbitraire. Par exemple, un serveur web comme nginx limite la taille de la requête d'un client à 1Mo (par défaut, c'est bien évidemment configurable).
Une stratégie possible est de diviser la taille totale de la mémoire par le nombre maximum de client à gérer pour définir cette limite. Si on 8Go et que l'on se limite à un maximum de 1024 clients, en imposant une limite à 8Mo par client, on est tranquille.
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi note par défaut à 1 dans les forums. Évalué à 3 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/c76fab77f73912a90b9a9ed9930afe4b5bca8011
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Ajouter la possiblité de suivre les nouveautés des tags via un flux RSS/ATOM. Évalué à 4 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/6681171e8536d5140be8288952cba841a8e32b30 et https://github.com/nono/linuxfr.org/commit/9fa2090a444c071b6a1c2fe281f93dd953d6a05c
# Bof
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Extraits de commentaires à 10 dans nos flux Atom news et journaux. Évalué à 3 (+0/-0).
Bon, le score de cette entrée de suivi est toujours à 0 => je la ferme.
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Mettre le lien pour tagguer à côté des tags. Évalué à 4 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/dc6cabc50ddaa658ca51cf33c3175131adf524d6
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi le lien "epub" pollue la navigation. Évalué à 3 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/dc6cabc50ddaa658ca51cf33c3175131adf524d6
[^] # Re: Trier par ?
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Je peux trier le tableau de suivi par colonnes en cliquant sur celle ci. Évalué à 3 (+0/-0).
Bon, vu qu'il ne manque rien, je ferme cette entrée.
# Heu...
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Message de confirmation d'inscription. Évalué à 3 (+0/-0).
On affiche déjà un message de confirmation à l'inscription. Il apparaît en haut de la page dans un cadre rose et il dit « Vous vous êtes inscrit avec succès. Vous allez recevoir les instructions de confirmation par courriel ».
[^] # Re: Catastrophique
Posté par Bruno Michel (site web personnel) . En réponse au journal Lolix. Évalué à 6.
Et ce sera le financement participatif : http://blog.rodolphe.quiedeville.org/index.php?post/2013/12/lolix-de-1998-a-2013 !
[^] # Re: Catastrophique
Posté par Bruno Michel (site web personnel) . En réponse au journal Lolix. Évalué à 4.
Il étudie différentes possibilités, cf https://twitter.com/rodoq/status/408974468791664640.
# Bouton en place
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Dépêche en rédaction : renvoyer vers journal ou pinguer l'auteur. Évalué à 3 (+0/-0).
On a maintenant un bouton pour relancer les rédacteurs d'une dépêche. Je pense que cela couvre les besoins de cette entrée de suivi, je la ferme donc.
# Bof
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Bouton « proposer sur LinuxFr ». Évalué à 3 (+0/-0).
Les boutons de partage sont utilisés pour créer des liens vers les articles et les partager sur les réseaux sociaux. Au contraire, sur LinuxFr.org, nous encourageons l'écriture de contenus propres au site et évitons de reprendre tel quel des contenus tierces, ou même juste un lien vers ceux-ci. Donc, je ne pense pas qu'un bouton de partage pour LinuxFr.org ait beaucoup d'intérêt. D'ailleurs, pas grand monde s'est manifesté dans les commentaires pour aller dans ce sens. Du coup, je ferme cette entrée de suivi.
# Bof
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Navigation dans les dépêches par date voire par mois. Évalué à 3 (+0/-0).
Bon, ça fait un bout de temps que cette entrée est dans le suivi et elle n'a pas l'air d'intéresser grand monde => je ferme.
# Vraiment trop compliqué
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi « Crowd optimization » du moteur de recherche interne. Évalué à 4 (+0/-0).
Cette entrée est vraiment trop compliquée, je laisse tomber.
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Bug du compteur de vote / seuil de vote. Évalué à 3 (+0/-0).
A priori, ça a été corrigé.
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi User_id dans la table logs en cas de fermeture de compte. Évalué à 3 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/71f6064ee28cc97ded3099cf008813640eccd06b
[^] # Re: Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Mauvais lien vers l'aide à l'édition. Évalué à 4 (+0/-0).
Ça ne me prend pas plus de temps de le faire moi-même que d'appliquer un patch. Donc je dirais que remonter le souci dans le suivi suffit.
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Mauvais lien vers l'aide à l'édition. Évalué à 5 (+0/-0).
Bien vu, j'ai corrigé le lien. Merci !
Cf https://github.com/nono/linuxfr.org/commit/46d7a361fbc5071a8295250ac26ce644c5dc98d5
[^] # Re: HTTPS
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Du chiffrement et de la sécurité sur LinuxFr.org (statut au 24/11/2013). Évalué à 9.
Si un utilisateur va sur la page en https et s'authentifie, on dépose un cookie pour faire la redirection automatique de http vers https (et le cookie d'authentification est envoyé en https uniquement). Par contre, nous ne souhaitons pas étendre ce mode de fonctionnement aux autres utilisateurs car il peut y avoir de bonnes raisons de ne pas pouvoir accéder au https (proxys d'entreprises qui refusent notre certificat par exemple).
# Corrigé
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Ne pas permettre de récupérer le titre d'un commentaire supprimé en y répondant. Évalué à 3 (+0/-0).
Cf https://github.com/nono/linuxfr.org/commit/6406dc3bccf4cdfb74ff3f945f9aa75aabd690d5
[^] # Re: Bundler et gemsets
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche L'admin pressé - RVM. Évalué à 4.
Une autre alternative à rvm est chruby. Je l'utilise depuis peu et je n'ai pas eu de soucis avec jusque là. Son côt minimaliste me plaît bien.
# Fait
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Dépêche Capitole du Libre. Évalué à 3 (+0/-0).
La dépêche est maintenant en phare (tout en haut de la page d'accueil).
[^] # Re: consensus & patch
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi HTTP GET 73 fois par jour depuis DLFP. Évalué à 3 (+0/-0).
J'ai appliqué tous les patchs et c'est en prod. Merci !
[^] # Re: interface avec autres lib en C ?
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 7.
On lance le binaire compilé.
Oui, les binaires sont bien en ELF.
Je ne suis pas sûr de comprendre la question. Les bibliothèques en go sont inclues dans le programme compilé (édition de liens statique).
Il utilise la libc standard.
On utilise les fonctions de la bibliothèque standard.
On utilise cgo. Cf http://blog.golang.org/c-go-cgo
[^] # Re: consensus & patch
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi HTTP GET 73 fois par jour depuis DLFP. Évalué à 3 (+0/-0). Dernière modification le 14 novembre 2013 à 10:50.
Pour tester, tu lances img, puis tu fais ça dans un terminal :
Oui, je m'étais déjà dit ça. Si je me souviens bien, le problème était l'absence de synchronisation entre le moment où l'on écrit le fichier sur le disque et les appels à redis. On pourrait effectivement se retrouver avec un mauvais Content-Type dans ce cas.
En pratique, ça m'avait l'air hautement improbable que ça se produise et, au pire, pas très compliqué à nettoyer à la main. Donc, j'ai du me dire que je verrais ça un autre jour ;-)
[^] # Re: Laissez malloc tranquille !
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Le langage Go fête ses 4 ans. Évalué à 4.
Le "raisonnable" dépend des cas. Ça peut être une valeur arbitraire. Par exemple, un serveur web comme nginx limite la taille de la requête d'un client à 1Mo (par défaut, c'est bien évidemment configurable).
Une stratégie possible est de diviser la taille totale de la mémoire par le nombre maximum de client à gérer pour définir cette limite. Si on 8Go et que l'on se limite à un maximum de 1024 clients, en imposant une limite à 8Mo par client, on est tranquille.