nicolabricot’s blog

C’est une bonne nouvelle pour les personnes hébergeant leurs sites web chez OVH !

L’hébergeur, qui est aussi un sponsor de Let’s Encrypt, a mis en place depuis quelques jours l’activation par défaut pour ses hébergements d’un certificat SSL gratuit fourni par Let’s Encrypt. Vous n’avez rien à faire, l’activation se fait automatiquement, pour votre site principal et ses sous-domaines s’il y en a.
Vous pouvez lire l’annonce d’OVH : « vos certificats SSL gratuits via Let’s Encrypt ».

Concernant le multisite — le fait d’héberger plusieurs noms de domaine différents sur une même instance d’hébergement — c’est aussi pris en compte. Marvellous :)
Mais attention c’est le même certificat SSL qui est partagé avec tous vos multisites ! Ce qui signifie qu’il est très simple, à partir d’un de vos sites, de savoir quels autres sites SSL sont liés à votre même instance d’hébergement.
Si vous souhaitez les cantonner, il vaut faudra ne pas activer le SSL, ou avoir un hébergement différent par site.

Pour les multisites, c’est un même certificat partagé qui est utilisé

Petit rappel pour forcer la redirection HTTP vers HTTPS (fichier .htaccess) :

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)^ https://domain.tld/$1 [L,R]

Bonne navigation chiffrée !

En cherchant une API pour récupérer les informations météorologiques de lieux d’intérêts, je suis tombé sur le service proposé par previsions-meteo.ch. Et j’en suis très, très satisfait.

Exemple d’utilisation : Weather Home Screen

Ses principaux atouts sont, à mes yeux :

• le fait qu’elle soit gratuite et publiquement interrogeable ;
• une documentation succincte mais complète ;
• différentes manières de récupération des données (iframe, image, JSON) ;
• les données « complètes » et bien fournies en JSON ;
• les prévisions jusque 4 jours.

Je regrette juste qu’il ne soit pas précisé le temps de mise à jour des données : pour ainsi implémenter judicieusement côté client la mise en cache des données et éviter des requêtes inutiles vers le serveur (actuellement j’ai une mise en cache de 30 minutes).

Il est aussi à noter que le service ne concerne que les villes en France, Belgique et Suisse.
Bonne intégration !

Pas plus tard que ce matin, j’envoie des fichiers, dont des images — de type PNG pour être exact — sur un hébergement OVH par le protocole FTP (via Filezilla).
Jusque là aucun souci, c’est de loin pas la première fois que je fais ça.

Oui mais cette fois, j’ai une erreur assez surprenante lorsque j’accède par l’intermédiaire de Firefox aux images uploadées :

L’image « failed.png » ne peut être affichée car elle contient des erreurs.

Il se peut que l’image ait été mal envoyée, je recommence donc le transfère des images uniquement car bizarrement :

• toutes les images contiennent des erreurs ;
• les fichiers autres que les images sont chargés correctement.

Sauf que cela ne change rien. J’essaie donc, dans le doute, avec d’autres navigateurs (Chrome, IE, …) mais sans succès. L’image ne se charge toujours pas correctement.
Je vous passe les autres essais infructueux pour tenter de résoudre le souci. Jusqu’à que j’aille regarder du côté du transfert FTP et de Filezilla. Bingo !

Par défaut — ou parce que j’avais précédemment changé le paramètre — le transfert se faisait en ASCII, et ça, pour OVH et les images, c’est le mal.
La solution était toute simple : forcer le transfert en « binaire » :-).

Note : le mode automatique est à préférer, Filezilla choisit automatiquement et intelligemment le bon mode de transfert en fonction du type de fichier.

Depuis maintenant presque sept ans — depuis l’ouverture en fait — le blog est hébergé sur les pages perso de Free. J’ai connu les configurations hasardeuses, les scripts bloqués, les configurations et réglages Apache interdits , … Jusqu’à présent je n’avais pas trop à me plaindre, car malgré ces restrictions, tout fonctionnait bien.

J’ai pu avoir quelques frayeurs, et j’avais pensé à passer à un hébergement un peu plus sérieux, mais voilà il n’y avait rien d’urgent et ça fonctionnait.

Sauf qu’il était temps de changer. Je ne sais pas si vous avez remarqué, mais les sites hébergés sur les pages perso de Free sont depuis quelques semaines d’une lenteur incroyable. À un point que je me suis demandé si Free n’avait pas bridé son système de pages perso et n’allait pas y mettre un terme.
J’ai pris les devant et je suis passé à l’offre de base chez OVH, bien adaptée pour les quelques sites à migrer avec peu de visiteurs.

La migration n’a pas été trop compliquée, même si j’ai eu du mal à obtenir un fichier de sauvegarde SQL complet du côté de Free. Une fois ce souci réglé, aucun autre problème à signaler.
J’en ai profité pour configurer des belles URLs pour Dotclear et la mise à jour de la dernière version, avec sa partie administration revue est très agréable !

Normalement la navigation devrait être beaucoup plus fluide et le temps de chargement très faible. Je vais surveiller les erreurs 404 pendant quelques temps histoire de m’assurer que les redirections se passent bien :-)
Et j’en profité pour faire quelques changements minimes sur le design.

Photo : Nathan O’Nions.

Le 25 mai 2007, j’ouvrais ce blog un peu avant de partir trois mois en Allemagne. À l’époque, je n’étais encore trop familier avec les technologies web, et j’apprenais seulement le HTML…
Je me souviens avoir longuement hésité pour choisir un système de gestion de contenu, avant d’installer Dotclear.

Aujourd’hui, cette initiative française, a 10 ans. Même s’il m’est arrivé de penser à migrer sur Wordpress, j’avoue qu’aujourd’hui je ne changerai pour rien au monde.

Bon anniversaire Dotclear :-) et longue route à toi !

Photo : Will Clayton.

J’ai d’abord cru à un spam.

Bonjour Nicolas,
Votre confidentialité est de la plus haute importance pour tous les employés de Facebook et nous nous attachons sans cesse à protéger vos informations. Bien que la plupart d’entre nous passent tout le temps à empêcher ou résoudre les problèmes avant qu’ils n’affectent quiconque, nous avons récemment été pris de court par un bug technique qui a divulgué votre numéro de téléphone ou adresse électronique à un tiers.

Le bug avait une portée limitée et n’a vraisemblablement permis qu’à une personne que vous connaissez déjà en dehors de Facebook de voir votre adresse électronique ou numéro de téléphone. Ceci dit, nous prenons cette erreur très au sérieux.

Décrire la cause du bug peut être un peu trop technique, mais nous voulons expliquer ce qui s’est produit. Lorsque les utilisateurs téléchargent leurs listes de contacts ou carnets d’adresses sur Facebook, nous essayons de faire correspondre ces données avec les coordonnées d’autres utilisateurs de Facebook afin de générer des recommandations d’amis. À cause du bug, les adresses électroniques et les numéros de téléphone utilisés pour créer ces recommandations et réduire le nombre d’invitations que nous envoyons ont été accidentellement stockés dans leur compte Facebook, avec leurs contacts téléchargés. En conséquence, si une personne avait téléchargé une archive de son compte Facebook via notre outil de téléchargement des informations, qui inclut les contacts téléchargés, elle a pu se retrouver avec des adresses électroniques ou numéros de téléphone supplémentaires.

Voici vos coordonnées (accidentellement visibles d’1 utilisateur Facebook maximum) :
[…]@[…]

Nous pensons qu’1 utilisateur Facebook a vu ces coordonnées supplémentaires affichées à côté de votre nom dans la copie téléchargée de ses informations de compte. Aucune autre information vous concernant n’a été affichée et il est fort possible que la personne ayant vu ces informations ne vous soit pas étrangère, même si vous n’êtes pas amis sur Facebook.

Nous reconnaissons que le partage accidentel de coordonnées est inacceptable, même si vous connaissez les personnes ayant vu ces coordonnées, et nous avons pris toutes les mesures nécessaires pour empêcher que cela ne se reproduise. Pour plus d’informations sur le bug, veuillez lire notre publication de blog.

Tous les employés de Facebook prennent ce problème très au sérieux. Nous vous remercions pour votre usage continu de Facebook et mettons tout en œuvre pour fournir le niveau de service que vous attendez et méritez.

Merci,
L’équipe Facebook

“Message important de Facebook” reçu par email

Je serais curieux de savoir comment Facebook a déterminé que seul un utilisateur ait pu accéder à mon adresse email.

Pour un projet de site web associatif, tout comme pour le blog ici, j’utilise des fontes provenant de la plateforme Google Web Fonts.
C’est un service très pratique qui permet d’utiliser la propriété @font-face de CSS pour utiliser une police d’écriture personnalisée.

Seulement, l’affichage n’était pas terrible du tout sur Windows, et uniquement avec le navigateur Chrome.
J’ai été très surpris qu’Internet Explorer affiche correctement les fontes, mais pas Chrome. Je me suis rendu compte que Chrome ne « forçait » pas le lissage de la police, ce qui donnait un aspect rugueux au rendu.

Mais j’ai trouvé une solution en suivant les conseils de Kévin décrits dans son article. Il suffit d’ajouter cette ligne (en adaptant la couleur naturellement) :

-webkit-text-stroke: 0.5px #333;

Le rendu est ce qu’il est, mais c’est déjà plus joli et agréable à l’œil.

Lorsque je suis passé sur Mac, j’ai voulu conservé mon navigateur habituel : Firefox. Mais au fil de mes pérégrinations sur le ouaib, je me suis aperçu que Firefox ne permettait pas de lire les fichiers PDF directement dans le navigateur. Il fallait toujours télécharger le document pour pouvoir le lire.

J’ai cherché s’il existait des solutions, mais rien de très excitant. Adobe^[1] ne propose plus son plugin PDF pour navigateurs sur Mac OS. Alors j’ai d’abord essayé PDF Browser Plugin mais ce n’était pas assez convivial et ergonomique à mon goût.

J’ai ensuite testé un plugin intéressant, PDF.js, un lecteur de PDF utilisant les standards web. Et je n’ai pas non plus été convaincu. Le projet était encore en développement, et sortait à peine des cartons.
J’ai alors délaissé Firefox au profit de Safari, pour qui le problème ne se posait pas. Seulement voilà, ce n’est pas Firefox.

Mais c’était sans compter mon envie de savoir si le problème n’avait pas été résolu entre temps… Je suis retombé sur la plupart des même articles qu’il y a une dizaine de mois, notamment sur l’article du support de Mozilla qui propose deux solutions : PDF.js et PDF Browser Plugin.
Mais voilà, la capture d’écran de PDF.js avait bien changé. Je l’ai donc réinstallé, sans grand espoir. Et bien je ne suis pas du tout déçu !

Outre l’interface beaucoup plus agréable et ergonomique, le visionnage est fluide et je n’ai pas encore eu de problème pour lire les PDF, même les formulaires de maths avec de jolies formules…

Bref, je suis conquis, et si comme moi vous voulez de nouveau pouvoir lire les PDF sur Firefox sous Mac OS, je ne peux que vous conseiller très fortement d’utiliser l’excellent plugin PDF.js (appelé aussi PDF Viewer) des Labs de Mozilla !