Cyril – Mes astuces

Le CSS évolue. Une des principales innovations dans ce standard est l’ajout des animations. En voici un aperçu.

Démo : opacité et rotation

Un peu de code

Principe de fonctionnement

Le principe des animations est simple :

1. Vous ajouter des styles à vos objets : style normal, et style modifié sur un évènement, par exemple avec :hover. Par exemple, on définit opacity: 0.5; dans le cas normal et opacity: 1; dans le :hover.
2. On rajoute un style normal qui s’intitule -webkit-transition et dans lequel on va programmer la transition : type de propriété à animer, courbe de vitesse. Par exemple, si on veut animer l’opacité avec une vitesse rapide, en rendant l’arrêt plus fluide : -webkit-transition: -webkit-transform 1000ms ease-out 40ms ;

Source de l’exemple

Compatibilité

Le grand problème des évolutions de langage, c’est qu’il faut attendre l’évolution des navigateurs. Parmi les navigateurs compatibles disponibles à ce jour, nous avons Firefox 4, Chrome et Safari.

Cependant, le manque de compatibilité, dans certains cas (opacité par exemple), ne rendra pas votre site incompatible, mais seulement moins fini.

Pour aller plus loin : la référence du w3 sur les transitions CSS3.

Envie d’avoir les notifications sous Firefox comme sous Chrome ? C’est désormais possible avec l’extension qui va bien.

Elle n’est pas encore tout à fait finie, mais c’est assez pour pouvoir s’en servir.

La page de l’extension : https://addons.mozilla.org/fr/firefox/addon/221523/
Site officiel : http://code.google.com/p/ff-html5notifications/

Aujourd’hui, j’ai cherché à injecter du code dans une page HTML depuis une extension Firefox. Ca permet de définir des objects dans le scope de la fenêtre, qui seront ensuite accessibles depuis le code javascript de la page. J’ai aussi cherché à communiquer dans l’autre sens : appeler des fonctions de mon extension depuis la page web.

Injection de script dans une page Web

L’injection se passe en deux étapes :

1. Il faut savoir sur quelle page intervenir : on peut donc se binder sur l’évènement DOMContentLoaded du navigateur ;
2. Il faut ensuite injecter le code à proprement parler, et qu’il soit visible.

Etape 1

Voici le code commenté (à inclure dans browser.xul) :

2. Injection de code

Et voici comment injecter :

Communiquer avec un script qui tourne dans le browser.xul

Communiquer dans l’autre sens a des intérêts : ça permet d’accéder à des fonctions plus avancée (accès à toutes les librairies XPCOM !).

La méthode est plutôt simple : on crée un élément dans le HTMLDocument (utile pour faire passer des données, en utilisant des attributs auxquels on aura ensuite accès), et on envoie alors un évènement personnalisé, sur lequel écoute notre Injector.

1. Ecoute des évènements de la page

On modifie le onPageLoad pour rajouter le bind sur les évènements, que l’on va ensuite traiter avec la méthode onEvent :

2. Envoi d’un évènement

Et voici le code à mettre dans votre page HTML :

Bibliographie

• Le code source de Firebug pour l’injection de code.
• Un post sur stackoverflow qui décrit la deuxième partie.

A la suite de cet article sur les cookies en navigation privée sous Chrome, Firefox et Internet Explorer, je me suis penché sur le cas Safari. La version que j’ai utilisée est Safari 5.0.1 pour Windows (avec wine 😉 ).

1^ère différence : des paramètres par défaut plus restrictifs

Par défaut, Safari n’autorise que les coookies « des sites que je visite ». Par défaut donc, Safari n’accepte pas les cookies tières. Cependant, il accepte tout de même de les supprimer (allez comprendre…).

2^ème différence : persistance des cookies

J’ai ensuite effectué les mêmes tests que pour les autres navigateurs, et là aussi le résultat diffère.

1. Je n’ai pas de cookies. Je passe en navigation privée, je récupère des cookies, et je repasse en mode normal. Là, tout est OK.
2. Je me prends des cookies. Je passe en navigation privée : les cookies sont toujours présents. Je cherche à les supprimer (avec les headers HTTP) : impossible, les cookies restent en place. En fait, les cookies reprennent alors la valeur qu’ils avaient avant le passage en navigation privée.

Conclusion

Safari se comporte réellement différemment que les autres navigateurs. La principale « fuite » d’information étant causée par les cookies tièrce, en ce sens le paramétrage par défaut de Safari est plus sécurisé. Cependant, le fait que l’on reste connecté après le passage en navigation privée est assez perturbant dès lors que l’on est habitué aux autres navigateurs. Mais le pire, c’est que l’on n’arrive pas à se déconnecter des services en mode de navigation privée.

Lien : outil de test utilisé pour afficher, écrire et supprimer des cookies

De plus en plus de navigateurs ont un mode de navigation privée. C’est le cas pour Chrome, Firefox, Safari et Internet Explorer (inPrivate) en autres. Ces modes permettent de surfer anonymement sur Internet. Enfin anonymement…

Concrètement : la navigation privée, ça change quoi ?

Le principe de base, enoncé dans une publicité pour le système d’exploitation de Microsoft Window 7, et son navigateur internet associé IE8, est le suivant : vous pouvez acheter un cadeau sur l’ordinateur commun en mode privé, et quand vous avez fini il ne reste plus aucune trace de votre passage dans votre navigateur. Ceci est correct pour la majorité des navigateurs.

Lorsque vous entrez en mode de navigation privée, le navigateur n’enregistrera rien de ce que vous faîtes : tout est stocké dans un répertoire à part, qui vous permet de garder votre historique et vos cookies (nécessaires sur presque tous les sites où vous avez un compte). A la fin, lorsque vous fermez le navigateur ou que vous choisissez d’arrêter votre session de navigation privée, tout est supprimé et vous retrouvez un navigateur comme si vous n’aviez jamais rien fait.

Voici les principales applications de la navigation privée :

• Pour faire un cadeau à quelqu’un, comme énoncé plus haut ;
• Pour aller sur des sites adultes (soyons honnêtes : sans doute la principale utilisation faite de ce mode de navigation)
• Pour prêter son ordinateur à quelqu’un (de confiance) temporairement : si cette personne se connecte à son compte Google par exemple, à la fin de la session vous serez toujours connecté à votre propre compte et non à celui de la personne à qui vous avez prêté votre ordinateur.

Question plus technique : les cookies

J’ai eu l’occasion d’effectuer différents tests sur Firefox 3.6, Chrome 5.0 et Internet Explorer 8 en utilisant cet outil. J’ai testé les cookies locaux et les cookies tièces. Pour les cookies tièrces, j’ai utilisé un script javascript distant pour lire et écrire les cookies. Les cookies distribués avaient une durée de vie de 1 journée (86400 secondes).

• Sans navigation privée : les cookies locaux et tièrces sont correctement stockés et redistribués aux sites ;
• Passage à la navigation privée : les cookies stockés sont perdus ;
• Pendant la navigation privée : le navigateur se comporte normalement, avec lecture et écriture des cookies locaux et tièrces ;
• A la fin de la navigation privée : les anciens cookies présents sont restaurés.

Le point qui me semble le plus important et le moins facile à deviner est donc la perte de toutes les cookies existant lors du passage en navigation privée.

L’anonymat sur Internet

Il existe bien des manières d’identifier une personne sur Internet. La méthode la plus sûre, et utilisée dans tous les cas (ou presque, j’imagine), c’est le cookie. Il permet vraiment d’identifier une personne derrière un écran. Mais il y a d’autres informations particulières qui, en dépit de ce que pourra faire votre navigateur, restent imprégnées sur la toile.

L’adresse IP : cette adresse est unique par foyer, et fixe dans la majorité des cas. Si vous n’avez qu’un seul ordinateur derrière une adresse IP, alors on peut aisément vous reconnaître, quel que soit l’ordinateur ou le navigateur que vous utilisez : vous êtes la même personne. De plus, il est facile de savoir si vous êtes seuls derrière : il suffit d’étudier le comportement de votre IP sur une petite attaque réseau bénigne lancée avec nmap par exemple.

Le User-Agent : si vous êtes plusieurs derrière une IP, on peut utiliser le User-Agent. Le User-Agent est une ligne de texte envoyée à tous les serveurs sur Internet qui permet de définir si vous êtes sous Mac ou PC, si vous utilisez Firefox ou Internet Explorer, si vous êtes sous Windows Vista ou Mac OS 10.4, ou encore sous iPhone ou Android… Comme deux ordinateurs dans une même maison sont rarement identiques (Système d’exploitation, Navigateur, et leur version associée), on peut reconnaître par exemple monsieur sous Windows XP et Madame sous Mac OS.

L’expérience de navigation : l’adresse IP pourrait tout de même être suffisante. Si vous êtes plusieurs derrière votre accès Internet à la maison, il n’en reste pas moins que chacun va sur les sites qui l’intéresse : Madame va lire Marmiton tandis que Monsieur va lire les Echos.

Conclusion

L’adresse IP est donc bien suffisante dans la majorité des cas pour identifier une personne,. En fait, l’anonymat sur Internet, vous pouvez l’oublier. Tout de même, il faudrait aller sur des sites peu scrupuleux pour avoir affaire à ce genre de pratiques (sites pornographiques, de Peer-to-Peer, …). Pour les autres, les systèmes de navigation privée proposés par les navigateurs sont bien suffisants.

Lien : outil de test utilisé pour afficher, écrire et supprimer des cookies

J’ai lu pas mal d’articles sur comment créer un cluster de session en PHP, afin de pouvoir utiliser plusieurs serveurs web en front tout en conservant les sessions entres les différents serveurs. Finalement, je vais expliquer la solution de repcached.

Memcached

Memcached est un serveur qui sert à enregistrer et redélivrer des valeurs diverses et variées directement dans la RAM d’un ordinateur.

Avantages : la rapidité d’éxecution des commandes et le support dans PHP en installant une simple extension PECL.
Inconvénient : perte des données en cas de reboot

Dans notre cas, pour stocker des sessions, c’est parfait : un accès rapide à des données, et plusieurs serveurs peuvent accéder à cette base de donnée en même temps.

Repcached

Repcached permet de pallier l’inconvénient de memcached : il s’agit simplement d’un patch qui permet de gérer la réplication entre deux serveurs. En effet, toute commande d’écriture sur un serveur est directement reportée sur l’autre serveur. Ainsi, si l’un des deux tombe, l’autre est à jour et peut prendre le relai. De plus, lors du reboot, toutes les données seront automatiquement récupérées auprès du premier serveur.

Cette solution permet du coup de gérer la redondance de l’information.

Puis-je mettre plus de 2 serveurs ?
Certainement, mais je ne sais pas trop comment… On pourrait mettre 3 serveurs en cycle, mais si l’un tombe, la chaîne est rompue. Il faudrait automatiquement adapter le routage des paquets non plus vers le serveur qui est tombé, mais vers le serveur survivant (en redirigeant les paquets par iptables par exemple).

Installation sous Gentoo

J’ai mis à disposition le serveur memcached 1.2.8 avec repcached 2.2 en ebuild à disposition ici :
http://cyril.me/ebuild/net-misc/memcached/

Cet ebuild se base sur la version 2.1-1.2.6 disponible dans l’overlay wolf32o1.

Consécutivement à l’article sur les notifications HTML 5, voici un article qui donne un exemple de fonctionnement des notifications.

La démo

Avant de pouvoir afficher une notification, vous devez autoriser le site à vous en présenter : Autoriser les notifications
Il y a parfois des limitations qui empêchent le site de lancer une autorisation au chargement de la page : vous êtes parfois obligé de faire cliquer l’utilisateur sur un bouton pour voir apparaître l’avertissement d’autorisation.

Ensuite, vous pouvez afficher des notifications (avec ou sans bouton) :
Afficher la notification
Programmer une notification dans 3 secondes

Sources de l’exemple

Code HTML :

Code javascript :

Parce qu’on n’a pas toujours le document au format qui nous convient, ou parce qu’on a parfois besoin de repasser par des chaînes de caractères pour passer des arguments ou stocker des variables, différents outils de conversion sont mis à disposition du développeur.

Conversion en passant par JSON

Certains types peuvent être convertis en passant par JSON : le texte, les objets, les tableaux, les nombres…

Du type javascript au texte : il faut utiliser JSON.stringify
Exemple : JSON.stringify([1,2,3]) => « [1,2,3] »

Du texte vers un type javascript : il faut utiliser JSON.parse
Exemple : JSON.parse(« [1,2,3] ») => [1,2,3] (où 1, 2 et 3 sont des entiers)

Conversion d’un document DOMDocument ou XMLDocument

Deux outils sont à disposition : XMLSerializer (du document vers string) et DOMParser (de string vers un document).

XMLSerializer : DOMDocument vers une chaîne de caractères
Exemple : s = new XMLSerializer(); var documentString = s.serializeToString(document);

DOMParser : Conversion d’une chaîne de caractères vers un objet DOMDocument
Exemple : p = new DOMParser(); var doc = p.parseFromString(‘<html><body>coucou</body></html>’, ‘text/xml’);

Compatibilité

Ces APIs sont compatibles avec, entre autres, Safari 4.0+, Chrome, Firefox 3.5+, et peut-être IE… 😉

Il peut être parfois nécessaire d’utiliser une iframe, pour accéder par exemple à des cookies sur un autre site, se logguer, etc. Le problème est que si vous utilisez une iframe sur un domaine différent, le navigateur va vous renvoyer une erreur.

iframe et sécurité

Lorsque les domaine ou port diffèrent entre les deux frames, le navigateur va refuser la communication. En effet, imaginez que vous puissiez afficher une iframe cachée dans votre page, pour ensuite y récupérer des informations sensibles.

Exemple : dans mon site example.org, je mets une iframe vers mabanque.com et je récupère les informations bancaires de l’utilisateur de mon site (si celui-ci est déjà loggué sur le site de la banque).

La solution

Pour autoriser la communication entre les frames, il faut utiliser le protocole de communication entre les fenêtres.

Cette communication se fait par évènement : une fenêtre envoie à l’autre un objet¹, qui le reçoit en ajoutant un handler sur l’évènement « message ».

Exemple

Dans notre exemple, l’iframe enverra un message à la fenêtre principale.

Fenêtre principale :

Fenêtre iframe

¹ : en fonction du navigateur, vous ne pourrez passer que des chaînes de caractères (Firefox 3.6 par exemple – Chrome supportant les objets). Pour pallier ce défaut, vous pouvez utiliser JSON.stringify et JSON.parse pour passer des objets comme des chaines ou des variables. Pour tout ce qui est DOM, ce n’est pas possible de faire passer les handler d’évènement définis dans la fenêtre source.

La question du jour : comment copier du texte en javascript.

En théorie

On va utiliser les objets suivants : la sélection DOM, et un Range.

La sélection DOM consiste en un objet, présent dans HTML5, qui permet de gérer les sélections de texte à l’intérieur d’un document.

Le range est un intervalle, qui permet de définir une zone continue dans un document.

En pratique, mis bout à bout

En pratique : on crée un range, on fait pointer la sélection dessus (en veillant à supprimer la sélection actuelle), et on exécute la commande « copy » pour copier la sélection dans le presse-papier.

Exemple : copier le code javascript (ne fonctionne qu’avec un navigateur compatible HTML5)