Cyril – Mes astuces

Pas de doute, le Responsive Web Design est à la mode. En même temps, pourquoi faire plusieurs site web à maintenir alors qu’un seul pourrait suffir ?

Se pose donc la question, pour les entreprises pour lesquelles le référencement naturel est important, de l’opportunité de passer en mode responsive.

Mobiles/Tablettes/Desktop : mêmes problématiques ?

1. Mon service est-il le même ?

L’une des questions qu’il faut se poser en premier : vais-je proposer le même service sur tablettes/mobiles et sur desktop ? Ou bien est-ce un service différent ? Pour un site de contenu, on proposera bien évidemment le même service, à savoir du contenu. Pour un site marchand, là encore le but est de vendre. Et dans certains cas la réponse va être différente. Si les utilisateurs n’ont pas le même usage, ou les mêmes intérêts sur mobile et sur desktop, un site dédié pourrait être mieux adapté. Dans l’exemple du site d’une banque, on mettra beaucoup plus en avant l’accès au compte, ou la localisation des agences que les services proposés par la banque.

2. Ma stratégie SEO est-elle du coup la même ?

Le principe fondamental du Responsive est donc que c’est le même contenu qui est proposé aux moteurs de recherches. Si la stratégie est différente, parce que les services sont différents, alors un site dédié pourrait être mieux adapté.

Responsive : c’est trop bien…

Nous avons déjà vu l’un des avantages : développer à moindre un coup à la fois un site desktop, mobile et tablette.

Par ailleurs, on peut aussi du coup s’affranchir des ennuyantes popup et autres headers où l’on nous propose de basculer vers une version mobile, en perdant du coup plus d’une fois sur deux l’information que nous sommes venus chercher.

Et côté SEO, ce sont les mêmes pages, le même contenu, pas besoin de se soucier du duplicate, et aussi un seul site à gérer.

… mais pas forcément tout le temps !

Le responsive est une technologie supportée par les mobiles et tablettes. Ces mêmes mobiles et tablettes utilisent des navigateurs beaucoup plus puissants que les vieux navigateurs encore installés sur la machine de Mamie (que vous devriez aller mettre à jour d’ailleurs) ou de certaines entreprises. A faire du responsive, on risque du coup de se priver de bon nombre de technologies développées depuis et très bien supportées sur 100% du parc visé.

De la même manière, les techniques utilisées pour assurer la compatibilité du code et du rendu entre navigateurs va alourdir le poids de la page, et n’est donc pas forcément adapté.

Enfin, charger la même image en version desktop/tablette/mobile n’est pas non plus une bonne pratique, car on va du coup télécharger sur notre mobile une image desktop que l’on n’affichera jamais ! Notez qu’il n’y a pas de problème avec les sprites, si vous en faîtes un par version.

Responsive pour qui ?

• si votre service et votre stratégie SEO sont identiques sur mobile/tablette et desktop ;
• si votre site n’a pas un design et une ergonomie trop compliqués (genre Metro Style), ou que l’on accepte certaines approximations (bord carrés, fond uni, …) ;
• si vous respectez les bonnes pratiques pour éviter de tout charger pour tout le monde (par exemple http://www.lukew.com/ff/entry.asp?1707)

Nginx est un très bon logiciel alternatif à apache ou lighttpd. Voici comment utiliser le protocole SPDY avec Nginx.

SPDY : c’est quoi ?

SPDY est un protocole Web qui vient entre le SSL et le HTTP. Le but est d’accélérer le téléchargement des données.

1. Le premier moyen d’accélérer la connexion est de faire du multiplexage, c’est à dire de faire passer plusieurs flux HTTP en parrallèle au travers de la même connexion. Ainsi, une seule connexion est requise.
2. Le deuxième moyen est de compresser les données qui ne le sont pas, notamment les entêtes HTTP.

Attention toutefois : SPDY n’est compatible que pour des URLs sécurisées (HTTPS) : « we believe that the long-term future of the web depends on a secure network connection » ( « nous pensons que le futur du web va s’appuyer sur une connexion réseau sécurisée »).

Enfin, SPDY est déjà compatible avec Chrome et Safari, et c’est déjà pas mal ! Voici ce lien pour une liste des navigateurs compatibles à jour.

Conséquenses sur le développement

Le protocole SPDY permet de s’affranchir de certaines règles qui permettent d’afficher plus rapidement une page web :

1. « moins » besoin de multiplier les noms de domaine des serveurs de fichiers statiques ;
2. pas besoin de faire de Sprites CSS, car le principe du sprite est d’utiliser la même connexion pour télécharger plusieurs images, mais en combinant toutes les images dans une seule.

Installer nginx-1.3.9 avec SPDY sous gentoo

Voici l’overlay à installer (ou bien récupérez juste l’ebuild et le patch !)

https://github.com/paxal/nginx-spdy

En savoir plus

• Description du protocole SPDY sur le site de chromium.org : http://www.chromium.org/spdy/spdy-whitepaper
• Une explication officielle (en anglais) : http://googledevelopers.blogspot.fr/2012/04/add-spdy-support-to-your-apache-server.html
• Une explication sur les performances réseau et SPDY : http://lincolnloop.com/blog/2012/jul/12/what-is-spdy/
• Les limites de SPDY : http://lincolnloop.com/blog/2012/jul/12/what-is-spdy/

Update 20.01.2013 : L’ebuild de la version nginx-1.3.11 avec spdy est disponible

Update 03.04.2013 : L’ebuild de la verstion nginx-1.3.15 avec spdy est désormais disponible sur le repository officiel de gentoo

« Mazette ! », comme peuvent dire certains ! Que de complications pour avoir accès à certaines fonctionnalités sur des Debian/Ubuntu ! (ci-après dénommées Debian tout court…)

J’ai récemment passé un serveur de Gentoo à Debian et voici les différentes difficultés que j’ai pu rencontrer…

Compilation avec des USE-flags incompatibles

Sur Gentoo, la vie est belle : j’ai besoin de telle fonctionnalité plutôt que de telle autre, je fais mon choix, puis j’emerge le programme. Tandis que sous debian… ah la la… obligé de compiler manuellement pour avoir les bons paramètres dans le ./configure. Résultat : une version compilée à la main, mais dans un répertoire dans un coin, qui ne profitera pas des nouvelles mises à jour.

J’en ai donc fait l’expérience avec PHP et le support des imageps*, ainsi qu’avec tinyproxy qui ne supporte pas la méthode Bind puisque compilé avec un mode « transparent » par défaut. Certes, il y a toujours moyen de contourner le problème du bind avec des règles de sécurité réseau, mais je fais quoi pour mon PHP ? J’ai les deux versions de script avec imageps* et imagettf*, et la version TTF n’est pas à mon goût au niveau de l’antialiasing de la police…

Init configurable

Pas le peine de lancer lighttpd alors que je ne l’ai même pas configuré ! Que se passe-t-il si le logiciel que se lance automatiquement fait planter ma machine à chaque fois (pas pratique d’utiliser le mode rescue pour ce genre de problème !) ou si la version du paquet contient des failles de sécurité ?

Gentoo : un monde imparfait…

Bon par contre, je les connais les problèmes avec Gentoo : configurer son boot (bootloader et kernel), mais avec de l’habitude ça passe plutôt bien ; ou encore attendre pas mal de temps pour compiler un programme genre LibreOffice (-bin ?) ou chromium (google-chrome ?).

J’ai aussi rencontrer des problèmes de stabilité dans certains programmes comme mysql-server ou lighttpd, et là je dois avouer que Debian m’a bien aidé !

Bon, j’arrête de troller…

Je vous ai déjà montré comment créer un certificat autosigné. Le problème de cette méthode, c’est que Chrome (par exemple) vous redemandera à chaque redémarrage d’accepter le certificat, ce qui plutôt pénible. Heureusement, voici la solution !

Autosigner un certificat avec une autorité

Pour que Chrome accepte votre certificat à chaque fois, il faut l’autosigner avec une autorité. Ensuite, il suffit de lui rajouter cette autorité dans la liste des autorités connues et le tour est joué !

Création de l’autorité

Nous allons créer la clé et le certificat permettant de signer d’autres certificats, et de se faire reconnaitre par les navigateurs. Ici, CA signifie Certification Authority.

1. Je crée une clé privée pour mon autorité. On vous demandera un mot de passe, qu’il faudra fournir à chaque nouvelle signature de certificat.
   openssl genrsa -des3 1024 > ca.key
2. Je crée le certificat d’autorité, celui que je vais importer plus tard dans Chrome. On va vous demander le mot de passe de la clé privée, ainsi que des informations sur l’autorité de certification que vous représentez. Ici, les données ont peu d’importance.
   openssl req -new -x509 -days 3650 -key ca.key > ca.crt

Création d’une demande de certificat

1. Création de la clé privée. On vous demandera ici aussi un mot de passe, celui de votre certificat final.
   openssl genrsa -out mondomaine.key 1024
2. Création d’une demande de signature CSR (Certificate Signature Request) : on crée un fichier contenant nos informations personelles, que nous transmettrons ensuite à notre autorité pour qu’il valide notre certificat. On vous demandera le mot de passe de votre certificat.
   openssl req -new -key mondomaine.key > mondomaine.csr

Signature du certificat

Il ne reste plus qu’à créer un certificat à partir du CSR en utilisant notre autorité.
openssl x509 -req -in mondomaine.csr -out mondomaine.crt -CA ca.crt -CAkey ca.key -CAcreateserial -CAserial ca.srl

La création du « serial » du certificat n’est nécessaire que la première fois.

Utilisation avec les navigateurs

Il ne vous suffit plus que d’ajouter le certificat de votre autorité CA.crt à la liste des certificats racines de votre navigateur, et tous les certificats émis par cette autorité seront automatiquement acceptés !

TL; DR

openssl genrsa -des3 1024 > ca.key
openssl req -new -x509 -days 3650 -key ca.key > ca.crt
openssl genrsa -out mondomaine.key 1024
openssl req -new -key mondomaine.key > mondomaine.csr
openssl x509 -req -in mondomaine.csr -out mondomaine.crt -CA ca.crt -CAkey ca.key -CAcreateserial -CAserial ca.sr

Netographie : linux-france.org : la création des certificats

Faire du HTML et du CSS est assez rébarbatif : toujours les mêmes balises, recopier les balises de fin, écrire des attributs class ou id… bref, un peu tout le temps la même chose en plusieurs exemplaires. C’est là que ZenCoding intervient !

Zen Coding, c’est quoi ?

Zend Coding est un plugin d’aide à la saisie pour votre HTML et votre CSS.

Concrètement, ça accélère la saisie, confère l’exemple ci-dessous !

Voici ce que l’on souhaite écrire comme code :

Et voici comment on va taper ça sur notre clavier :

div#content>ul.list>li*3 <Commande magique qui dépend de l'éditeur>

Fonctionnement

D’une manière plus générale, Zen Coding va interprété ce que vous venez d’écrire pour le transformer en code.

Dans notre exemple, nous avons utiliser une notation très proche du CSS pour écrire de l’HTML sans effort !

Mais ça marche aussi avec le CSS, notamment pour les attributs un peu long à écrire (ou à faire auto-compléter par l’éditeur), voire pour les valeurs. Il est en effet plus rapide de taper d:n<TAB> que display: none; avec la majorité des outils d’autocomplete.

Compatibilité

Le plugin est compatible avec énormément d’IDE, tels que Eclipse ou Vim (pour mon utilisation personnelle).

Plus d’informations sur le site de Zen Coding (hosté sur google code).

Nous y voilà ! Comment sniffer l’HTTPS ? Et bien c’est possible… et voici comment !

0. Préambule

Sniffer le trafic HTTPS est plus compliqué : soit vous décryptez les trames SSL (ça peut prendre du temps…), soit vous vous faîtes passer pour le serveur. HTTPS chiffre toute la connexion, par conséquent il n’est pas possible de récupérer les URLs, ni même le nom de domaine vers lequel les requêtes sont envoyées, vous n’aurez que l’adresse IP, ce qui est bien mais insuffisant !

Alors comment récupérer les données qui passent à travers le SSL ? En redirigeant tout le trafic vers un serveur sur notre machine, déchiffrer, puis jouer le rôle d’un proxy pour finalement renvoyer les données au vrai serveur.

Dans cet article, on va essayer de lire ce qui se passe avec www.paypal.com

1. Sniffer le trafic du mobile

Vous pouvez vous référer à l’article précédent Sniffer le trafic d’un iPhone/Android avec Linux.

2. Quel domaine ?

Comme je l’ai dit, on ne peut pas retrouver quel domaine est interrogé par un webservice en lisant la trame SSL. Mais on peut regarder de quelle IP notre mobile a besoin !

Pour récupérer le nom de domaine, il suffit donc de regarder quelles sont les requêtes DNS qui passent, et de regrouper les adresses IPs données avec l’IP du trafic SSL.

En l’occurence, il s’agira de www.paypal.com.

3. Déchiffrer : stunnel

On va utiliser le fabuleux programme stunnel pour lire le trafic SSL.

stunnel est un programme qui permet en gros d’utiliser SSL pour les clients et les serveurs qui ne le supporte pas. On va donc déchiffrer / rechiffrer le trafic pour le lire en clair.

3.1 Stunnel 1 : accéder en clair à un serveur https

Iil faut configurer stunnel :

pid = /var/run/stunnel-client.pid
client = yes
[www.paypal.com]
accept = 127.0.0.1:50000
connect = www.paypal.com:443

Si vous allez sur http://127.0.0.1:50000/ et que vous acceptez le certificat, vous devriez avoir une page HTML en résultat, signe qu’on a bien été connecté avec paypal.

3.2 Rediriger le trafic SSL vers un serveur sans SSL

Il nous faudra un certificat autosigné, puis créez un fichier mondomaine.pem qui contient la clé et le certificat :

cat mondomaine.key mondomaine.crt > mondomaine.key

Ensuite, il faudra bien configurer stunnel :

pid = /var/run/stunnel-server.pid
client = no
cert = /path/to/www.paypal.com.pem
key = /path/to/www.paypal.com.pem
[www.paypal.com]
accept = 0.0.0.0:50001
connect = 127.0.0.1:50000

Lancez stunnel avec ce fichier de conf : vous devriez pouvoir vous connecter sur https://127.0.0.1:50001/ en acceptant le certificat.

4. Rediriger le trafic provenant du mobile

Pour rediriger le trafic provenant du mobile vers notre serveur, il faut utiliser iptables :

$ iptables -t nat -A PREROUTING -d www.paypal.com -p tcp --dport 443 -j REDIRECT --to-ports 50001

Si vous allez depuis votre mobile sur https://www.paypal.com/, vous devriez avoir une alerte de certificat. Acceptez cette alerte : vous devriez avoir paypal.com, mais en passant par votre serveur.

5. Mais je ne vois toujours rien en clair…

Le trafic en clair passe sur votre localhost : utilisez donc wireshark sur cette interface…

6. C’est pour débugger une app et ça marche pas…

… parce que votre certificat n’a pas été validé par une autorité, et ne le sera jamais ! Envoyez le certificat .crt sur votre mobile (par email ?) et installez-le sur votre mobile

Générer un certificat autosigné, c’est générer un certificat pour un nom de domaine précis, sans que ce certificat ne soit valide aux yeux du navigateur. Néanmoins, ce certificat peut être importé dans une base de certificat, ce qui permet d’éviter les alertes de sécurité.

Il ne s’agit pas ici de sécurité, mais plutôt de générer un certificat pour un nom de domaine donné et de le faire accepté par un navigateur.

Le certificat doit comporter une clé privée

openssl genrsa -out mondomaine.key 1024

Et un certificat public

openssl req -new -x509 -days 365 -key mondomaine.key -out mondomaine.crt

C’est fini ! Quand on vous demande des champs, remplissez bien votre nom de domaine lorsqu’on vous demande le CN (Common Name, eg YOUR NAME).

Pour sniffer le réseau, nous allons transformer notre ordinateur sous Linux en routeur Wifi pour notre mobile.

Téléchargez le script sniff.sh, qui reprend toutes les étapes de ce tutorial, et modifiez-le à votre guise !

Avec ce système, l’ordinateur est connecté au réseau filaire pour Internet, et l’iPhone sera connecté à l’ordinateur via la carte réseau. Il est aussi possible de connecter l’ordinateur à Internet via wifi avec une deuxième carte réseau sans fil.

1. Désactivez votre gestionnaire réseau

Tous les gestionnaires réseaux ne sont pas capables de gérer plusieurs connexions réseau en même temps. Du coup, on désactive le gestionnaire réseau pour tout configurer manuellement (à l’ancienne !)

$ /etc/init.d/wicd stop
$ /etc/init.d/NetworkManager stop
$ ...

2. Votre connexion Internet

Réactivez votre connexion internet : si vous êtes en ethernet par exemple, vous pouvez exécuter dhcpcd eth0. Si vous êtes en Wifi, reportez-vous à la configuration de wpa_supplicant (mais vous aurez besoin d’une autre interface Wifi pour votre mobile !)

Ensuite, pour que votre ordinateur transfère les paquets, il faut activer le NAT :

$ iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE # Active le NAT : changez eth0 par le nom de votre interface réseau Internet
$ sysctl net.ipv4.ip_forward=1 # Active le routage des paquets via votre ordinateur

3. Votre connexion Wifi

Pour transformer votre ordinateur en routeur, il faut configurer le wifi et le DHCP (facultatif) pour aider votre mobile à se connecter.

Configuration du Wifi

On configure l’interface pour lui donner un nom Wifi, et une adresse IP :

$ iwconfig wlan0 mode ad-hoc # passage en mode ad-hoc : on autorise un autre device Wifi à se connecter avec nous
$ iwconfig wlan0 essid RouteurMobile # Nom de votre réseau
$ ifconfig wlan0 10.10.10.1 # L'adresse IP de votre carte réseau Wifi

Sans DHCP

Vous pouvez connecter votre mobile dès à présent pour utiliser votre réseau, mais il faudra alors lui donner les paramètres suivants :

• IP : 10.10.10.2
• Gateway/Passerelle : 10.10.10.1
• Netmask : 255.255.255.0 (ou 255.0.0.0 si vous voulez – ça importe peu)
• DNS : on va utiliser les DNS de Google : 8.8.8.8 et 8.8.4.4

Avec DHCP

Sinon, vous configurez votre routeur linux pour fournir ces paramètres via un serveur DHCP. Cela évite de rentrer manuellement sur le téléphone les paramètres de la connexion IP.

Pour ce faire, commencez par installer le serveur dhcpd. Ensuite, paramétrez comme suit votre fichier (/etc/dhcp/dhcpd.conf) :

option domain-name-servers 8.8.4.4, 8.8.8.8;
default-lease-time 600;
max-lease-time 7200;
subnet 10.10.10.0 netmask 255.255.255.0 {
  range 10.10.10.10 10.10.10.20;
  option routers 10.10.10.1;
}

Vous pouvez télécharger un exemple de fichier de conf dhcpd.

Puis démarrez votre serveur : /etc/init.d/dhcpd start

4. Connexion

Si tout s’est bien passé, vous verrez votre réseau créé sur votre mobile, et vous pourrez vous connecter dessus sans problème.

5. Sniffer avec Wireshark

Je vous propose d’utiliser wireshark pour sniffer le trafic.

Quelques filtres :

• http : affichera les requêtes HTTP, mais uniquement les paquets de questions (GET, POST, …) et ceux de réponses (HTTP/1.0 200 Ok, …)
• dns : les requêtes DNS
• dhcp : utile pour débugger le trafic DHCP

Problèmes fréquents

• Mon réseau n’apparait pas : vérifiez que la carte wifi de votre linux est bien configurée avec iwconfig et que l’interface est up : ifconfig wlan0 up
• Je me connecte mais je n’ai pas l’icône wifi, et pas d’adresse IP ou une adresse IP en 169.254.* : votre serveur DHCP ne fonctionne pas. Relancez-le et vérifiez sa configuration.
• Je suis connecté mais je ne vois rien dans Wireshark : vérifiez que vous avez sélectionné la bonne interface à écouter ! Aussi, utilisez votre iPhone pour aller sur Internet un peu

Ceci n’est qu’une étape vers un prochain article : sniffer des connexion HTTPS !

Ajout/enlèvement d’évènements sur des objets

En javascript, on peut aisément rajouter des évènements sur des objects en utilisant la méthode addEventListener et en supprimer avec removeEventListener.

Exemple : cliquez-moi

Pour enlever l’évènement, il suffit d’appeler removeEventListener sur le même objet avec le même deuxième argument.

Les fonctions anonymes

Les fonctions anonymes vous evitent de déclarer une fonction dans votre scope : vous ne la déclarez que quand vous en avez besoin.

Exemple : cliquez-moi

Mais impossible de supprimer l’évènement, car si vous appelez removeEventListener avec le même code, l’interprêteur Javascript va créer un deuxième objet fonction effectuant le même code, à la volée.

Les fonctions anonymes nommées

Pour résoudre ce problème, il suffit de nommer la fonction anonyme.

Exemple : cliquez-moi

Compatibilités avec les navigateurs

Et qui n’est pas compatible ? IE8 et les versions précédentes ! Donc ceci est surtout un memo pour le développement d’extensions avec Firefox, Safari et Chrome, et est très utile si (par hasard) vous écrivez un bootstrapped add-on.

Là je dois dire que ça m’a bien surpris ! En regardant les entêtes HTTP de booking.com, je suis tombé là dessus :

X-Recruiting: Like HTTP headers? Come write ours: booking.com/jobs

Ce qui veut dire : "Vous aimez les entêtes HTTP ? Venez écrire les nôtres : booking.com/jobs".

Y’en a qui ne manquent pas d’inventivité !

Comment lire les entêtes HTTP

• avec wget : wget -S -O /dev/null http://www.booking.com/ ;
• avec Firefox : ouvrez la console développeur (Ctrl+Shift+K ?) et tapez l’url du site dans la barre d’adresse. Cliquez ensuite sur la première requête GET ;
• avec Chrome (et Safari ?) : ouvrez la console développeur webkit et tapez l’adresse du site dans l’onglet d’où vous venez.

Et en plus ça leur fait des liens externes (certes pas très pertinents en occurrence)…