Réduction du nombre de clés de cache avec Magento

magento_logo

Magento offre une grande souplesse pour la personnalisation du rendu front office. Chaque catégorie, chaque produit peut avoir un design personnalisé.
En contre-partie, il y a, à minima, autant de clés de cache que de pages CMS, catégories et produits. Si la personnalisation n'est pas utilisée, elle peut êtres désactivée pour améliorer les performances. Je vais donc vous montrer dans ce billet comment réduire les clés de cache pour le front office.

Améliorez les performances avec Spring-Ehcache: Cache & @Cacheable

Le recours à l'emploi de caches dans nos projets permet d'améliorer significativement les performances.

logo-ehcache.png

Dans ce billet contrairement à celui-ci nous ne codons rien dans la partie métier pour éviter le couplage.

Spring sait rendre les choses simples plus simples et les choses complexes possibles.

Un cache sert à optimiser les accès aux données néanmoins ce n'est la solution miracle à tous les problèmes de performances.

Mais une fois mis en œuvre à bon escient, on se demande comment peut-on s'en passer.

Donc depuis Spring 3.1, implémenter une gestion de cache devient possible sans trop écrire du code.

La démo ci-après, sans aborder les détails d'implémentation de la couche DAO, présente un exemple concret de mise en (EH)cache.

Sachez néanmoins que les illustrations données reposent sur une implémentation basée sur spring-data.

Spring offre une implémentation light de mise en cache qui ne peut satisfaire les besoins de nos projets.

C'est pour cette raison qu'ici nous utilisons Ehcache.

L'annotation @Cacheable de Spring apposée sur les méthodes (finder par exemple) suffit.

L'AOP Spring rend la gestion du cache facile à l'instar des transactions déclaratives.

Devoxx France 2012 – Cache Java avec Guava

A l'occasion de Devoxx France 2012, j'ai assisté à la conférence intitulée Cache Java avec Guava présentée par Charles Fry.

La librairie Guava Cache fonctionne un niveau au dessus de ConcurrentHashmap mais n'offre pas autant de fonctionnalités que Ehcache. Les caches de Guava ne sont pas pré-chargés par défaut et sont tous thread safe. Le chargement d'un cache se fait avec une implémentation de la classe abstraite CacheLoader.

La construction d'un cache se fait progressivement, en commençant par un appel à la méthode statique CacheBuilder.newBuilder(), puis en chaînant les appels aux méthodes de la classe CacheBuilder. Cela permet de spécifier sa configuration et notamment sa stratégie d'éviction des valeurs : valeur utilisée le moins récemment avec expireAfterAccess(long, TimeUnit), valeur modifiée le moins récemment avec expireAfterWrite(long, TimeUnit) ... En plus du temps qui s'écoule, l'éviction de valeurs peut aussi être déclenchée en spécifiant le poids total maximum du cache par un appel à maximumWeight(long), qu'il faut combiner avec un appel à weigher(Weighter) pour indiquer comment peser une entrée du cache.
La construction du cache se termine en appelant build() ou build(CacheLoader), qui renvoient une nouvelle instance de Cache.

En plus des fonctionnalités classiques, les statistiques du cache peuvent être activées en appelant recordStats(). L'utilisation de la méthode removalListener(RemovalListener) permet de savoir quand une valeur vient d'être supprimée du cache. Par défaut, cette notification est synchrone, ce qui peut ralentir les opérations sur le cache. Pour traiter les notifications de manière asynchrone, vous pouvez encapsuler votre RemovalListener en appelant RemovalListeners.asynchronous(RemovalListener, Executor). Lors de la construction du cache, en appelant refreshAfterWrite(long, TimeUnit), on programme le rafraîchissement automatique d'une valeur un certain temps après sa création ou sa dernière modification. Dans certains cas, il peut être plus intéressant de charger toutes les valeurs du cache en une seule fois en surchargeant la méthode CacheLoader.loadAll(Iterable).

Parmi les autres fonctionnalités, on trouve Cache.get(K, Callable) pour récupérer une valeur dans le cache en spécifiant comment l'y ajouter si elle est absente. Dans ce cas, un unique appel au Callable est fait par le cache, même si plusieurs threads demandent la valeur pour cette clé. Enfin, il est possible d'obtenir une vue du cache sous la forme d'une ConcurrentMap en appelant asMap().

TechEvening à Lyon sur la sécurité des applications Web

Ce lundi s'est déroulé à Lyon un TechEvening consacré à la sécurité des applications Web. Nous avons testé les différentes techniques et outils utilisés par les utilisateurs malveillants. Deux applications ont été utilisées, l'une en J2EE pour la plupart des techniques (WebGoat 5.3 de la fondation OWASP) et l'autre en ASP.NET MVC 3 pour un focus sur les perfides attaques CSRF.

Au programme:

  • Injection: diverses techniques d'injection SQL;
  • Cross-Site Scripting (XSS): techniques de phishing et de "session hijacking";
  • Violation de gestion d'authentification et de session: technique de "session fixation";
  • Références directes non sécurisées: techniques d'"AC Bypass" aux niveaux données et métier;
  • Cross-Site Request Forgery (CSRF): technique du "Token Bypass";
  • Mauvaise configuration de sécurité: technique de "Malicious File Execution";
  • Stockage cryptographique non sécurisé: sensibilisation au "hashing" et "salting";
  • Manque de restriction URL: technique du "forced browsing";
  • Protection insuffisante de la couche transport: "sniffing", "ARP spoofing" et "ARP poisoning"
  • Redirections et renvois non validés: techniques du "HTTP splitting" et du "cache poisoning"

Nous avons utilisé les outils suivants:

  • Firefox
  • Fiddler
  • Firebug
  • TamperData
  • WireShark

Vous pouvez retrouver ci-après tous les supports:

  • L'application WebGoat 5.3;
  • L'application CSRFDemo ASP.NET MVC 3;
  • Les slides (PPTX ou PDF) de présentation;
  • Quelques fichiers utilisés pour les attaques;

Pour ceux qui s’intéressent plus globalement à la sécurité des applications .NET (pas qu'en Web), je vous invite à lire l'article suivant sur l'altération des assemblages, l'injection de code et la suppression des signatures cryptographiques. Une vidéo est également disponible.

jQuery et Ajax

Ajax

ajax_logo.png

Apparu en 2005, Ajax (Asynchronous JavaScript and XML) regroupe un ensemble de technologies déjà existantes, notamment HTML, JavaScript et XML. Avec Ajax, les applications web peuvent mettre à jour partiellement la page affichée par le navigateur sans avoir à recharger la page entière. L'interface graphique peut ainsi évoluer par petits bouts, devenant ainsi plus interactive et reproduisant la sensation d'utiliser une application type client lourd. Nous parlons alors d'applications RIA (Rich Internet Applications). Le terme "Asynchronous" signifie que l'exécution du JavaScript continue sans attendre la réponse du serveur qui sera traitée quand elle arrivera. En mode synchrone, le navigateur est "gelé" en attendant la réponse du serveur.