mar 31

La dernière version de Magento est sortie cette nuit et avec elle arrive l’option tant attendue : le Flat Catalog!

Celle-ci a été annoncée par Varien comme salvatrice pour les performances de notre outil e-commerce préféré (le site annonce un bénéfice de 40% sur le temps de chargement des pages en front office et sur l’utilisation de la mémoire).

Concrètement, que se cache-t-il vraiment derrière cette option « magique » et quel impact aura-t-elle sur les prochains projets construits sur la base de cette version?

Avant toute chose, rappelons que Magento repose actuellement sur un modèle de données de type « EAV » (Entity-Attribute-Value). Ce qu’il faut comprendre c’est qu’un objet « Produit » dans Magento n’est pas stocké dans une seule table mais éclaté dans un ensemble de tables en fonction des attributs de notre produit. Cette complexification du modèle de données se justifie en grande partie par la souplesse que propose Magento dans le paramétrage de nouvelles caractéristiques pour un produit.

Mais cette souplesse a donc un coût puisqu’il multiplie de manière importante le nombre de requêtes effectués en base pour un seul produit. On touche donc très vite aux limites de ce modèle dès lors qu’on travaille avec un catalogue important (plus d’une dizaine de millier de références). Varien a donc annoncé en début d’année qu’ils proposeraient une simplification de ce modèle sous forme d’une option librement activable depuis le back office pour permettre de basculer vers un modèle de données « à plat ».

En regardant de plus près, cette option est un peu plus subtile que ce à quoi on pouvait s’attendre: une fois le mode ‘flat catalog’ activé dans l’administration, on se retrouve finalement avec deux catalogues: un pour le backoffice, et un pour le front:

  • celui du backoffice reste le catalogue EAV tel qu’il existe dans la 1.2
  • le front utilise des nouvelles tables catalog_category_flat et catalog_product_flat
  • il y a une synchronisation type maître-esclave entre le catalogue backoffice et celui du front

Finalement, le « flat catalog » du front est en réalité une sorte de table de cache pour le vrai catalogue qui reste en EAV.

Les avantages de ce fonctionnement:

  • la migration est bien plus simple puisqu’en réalité le format de la base n’a pas vraiment changé (les tables _flat sont générées à la demande depuis le backoffice)
  • on peut imaginer facilement avoir une base de données front avec les tables _flat côté frontoffice, séparées physiquement de la base de backoffice, avec le moteur Federated de MySQL qui permet de présenter plusieurs bases de données comme en étant une seule aux applications. De ce fait, la charge sur le front n’impacte pas le back et inversement

Les inconvénients:

  • avec des volumétries très élevées, (certains) écrans du backoffice vont être très lents puisqu’ils continueront à utiliser le système EAV
  • les imports devront continuer à se faire dans les tables EAV, d’où une lenteur au moment de l’import (à nuancer: si les données importées ne sont pas destinées à être utilisées dans le backoffice, il est peut être possible de les importer directement dans les tables _flat du front)

Nos premiers tests sur la base de ce nouveau modèle et d’un catalogue de plus d’un million de produits devraient désormais nous fixer assez rapidement sur la pertinence de cette fonctionnalité…

A suivre donc!

écrit par Frédéric de Gombert \\ tags: , , ,

mar 26

Bonne nouvelle les amis !

Suite à :

  • de nombreuses demandes
  • des feedbacks positifs du premier opus
  • un besoin de la communauté de se « re » rencontrer
  • au fait que l’on a pas pu recevoir tout le monde sur le premier Bargento
  • à une grosse envie de boire « une bière communautaire »

On a décidé de remettre ça.

Ce coup-ci, peu de chances que l’on ait nos amis de chez Varien.

Roy préfère avoir Yoav (son directeur technique) dans les meetings, notamment pour les questions sur la roadmap et nos deux compères seront déjà à Londre fin Mars donc peu de chance qu’ils reviennent en Europe rien que pour nous fin mai.

J’essaye malgré tout de décrire à Roy l’enfer que les chromosomes XY vivent en mai en France, avec toutes nos belles compatriotes qui misent à 200% sur leur sex appeal de printemps, mais il faut avoir connu ça pour ne pas pouvoir y résister.

Donc probablement sans Roy mais avec :

  • Zend <————— new :-)
  • NBS System
  • SQLi
  • Baobaz
  • Fragento
  • Magavenue <——- new :-)
  • Faak
  • SeL, Capitaine commerce, François Ziserman
  • Toute la communauté !!!

Et toute la communauté qui voudra venir. Si on s’en tient à nos projection et au Bargento I, ça devrait faire dans les 200 à 300 personnes sur une journée. Bref, tout cela commence à s’organiser, ça ne sera probablement pas un Barcamp à proprement parler car on aura un peu trop de monde pour ce format, mais on gardera un espace « prise de contacts » et « discussion sur un point précis ».

Prochain mouvement, on voit quelle date est la plus consensuelle pour organiser BaRgEnTo II :
[Modification du 30/03/2009 : On passe le sondage en PollDaddy, les résultats déjà enregistrés seront reportés dans PollDaddy]

écrit par Philippe Humeau \\ tags: , ,

mar 23

Aujourd’hui, je prêche pour ma paroisse ! Ayez un bon hébergeur !
Pourquoi ? Entre autre pour : le temps de réponse…

Que coûte t’il ? Est-ce qu’il fait une réelle différence dans l’E-commerce et si oui, à quel point, quand, pourquoi ?

Sans vouloir répondre à toutes ces questions exhaustivement, le retour d’expérience des grands sites, les études psychologiques et les constats peuvent permettre de quantifier.

L’impatience de l’age

Depuis que l’homme est équipé de pouces opposables, d’une connexion ADSL et d’une culture Internet, il est impatient. C’était surement vrai avant quand les marquis courraient dans les jardins royaux à la suite de croupes rebondies, mais c’est d’autant plus vrai pour les jeunes vingtenaires ou les adolescents qui n’ont jamais réellement connus l’attente avant d’avoir un résultat, tout au moins sur l’informatique. (pour le reste, les femmes se chargeront d’enseigner la patience aux jeunes mâles)

Le temps à laquelle la réponse est reçue, après que la demande ait été envoyé, est d’une importance colossale mais il doit être d’autant plus réduit que le potentiel acheteur est jeune.

Grand mère attendra 20 secondes la page Web du site avec les gentils dauphins pour réserver ses vacances. Hugo, 14 ans et toutes ses dents, au delà de la deuxième seconde d’attente, il se demande si les pages du site sont acheminé par pigeons voyageurs ou à dos de hamster.

Les 4 temps du cerveau

un à cinq dixième(s) seconde : C’est la limite à laquelle on estime inconsciemment avoir une action immédiate sur ce que l’on manipule. Un applicatif lourd (riche), une interface graphique d’OS ou de téléphone doit réagir dans cette zone pour être apprécié. Dès les 5/6 dixième, l’esprit perçoit un léger ralentissement entre les ordres envoyés, l’action des mains et le résultat perceptible visuellement à l’écran. C’est la différence de réactivité entre l’interface d’un Iphone et celle d’un autre tactile, c’est également la différence de réussite du produit ! Le cerveau interprête, commande, reçoit, comme si l’outil utilisé était un prolongement du corps qu’il contrôle directement.

cinq dixièmes à 1 seconde : La perception se modifie, on est plus face à un système « temps réel », on ne contrôle pas directement. Le léger décalage entre la demande et la réponse est présent, c’est le contrôle  directe au bout du doigt qui n’existe plus. Le cerveau assimile l’information et n’a plus cette illusion de pouvoir contrôler l’interface comme il contrôlerait un membre du corps.  Ceci étant, sur le Web, l’internaute est habitué à ce délai et le cerveau est encore en attente de la réponse, pour peu de temps cependant.

2 à 10 secondes : Le cerveau n’attends plus la réponse directement, il vagabonde déjà à d’autres pensées. Le site visité n’a plus l’exclusivité de l’attention de l’internaute. Il se demande s’il ne va pas aller sur un autre site concurrent, si il a payé ses impots, si le webmaster lui envoie les pages par la poste et si son ticket de parking est toujours valable. Parlant de parking, il va vérifier à la fenêtre et en revenant appel sa femme pour savoir s’il doit aller prendre les gremlins à la crêche ce soir, bref, la vente ne se fera pas.

10 secondes : Quand on parle de se faire servir un sandwich, c’est un record, sur le Web c’est une impasse. A moins d’avoir l’exclusivité du produit ou de l’info, plus des deux tiers des internautes sont envolés. Si un chargement doit durer ce temps, il est indispensable d’occuper l’espace visuel de l’internaute pour garder son attention. Une petite hélice qui tourne, une barre de chargement, un pourcentage, qu’importe tenter de garder l’attention plus de 10 secondes sans occuper un des sens est illusoire.

Qu’y perd-on ?

Le chiffre de « -1% de CA par 0,1 s de latence » qui est retenu depuis l’étude d’Amazon est affolant !

La homepage d’amazon aujourd’hui fait 491 Ko, ma liaison, mon browser, mon os et tout ce qui contribue à la vitesse ou non du chargement font que j’ai visuellement une réponse en 2,2 seconde et un page complètement chargée en 6,2 secondes.

Reprenons le calcul d’Amazon : 0,1 seconde de plus, -1% de CA.

0,1 seconde sur les 2,2 seconde de temps de réaction visuel, c’est 4,5% du temps global avant que l’oeil ne perçoive un changement. Si on multiplie simplement ces valeurs par 5, pour une demi seconde, on perd 5% de CA ? Pour 2 secondes c’est 20 % de CA qui s’envolent ?

Mais la perte va bien au delà de l’internaute qui se désintéresse.

La double peine

Si le site est indisponible, lent ou inconstant dans ses performances, non seulement l’internaute risque de s’en désintéresser mais en plus, les moteurs de recherche vont le pénaliser.

C’est vrai pour les adwords de google, pour le référencement naturel également (voir la page de google sur ce point), mais bien sûr pour Yahoo aussi (cf Yslow :) ) et pour de nombreux autres.

Être lent ou indisponible va donc « froisser » les Bots qui vont « noter » le site un peu moins favorablement.
Du coup le référencement naturel en souffre aussi et les clients trouvent moins facilement le site et ses produits.

La perte quand un site rame n’est donc pas que de l’image et des commandes mais également de la visibilité.

De très nombreux facteurs influent sur la rapidité

Et un certain nombre sont incontrôlable par le commerçant ou l’hébergeur, comme notamment les performances de la machine cliente du site et de la connexion ADSL du client. Mais un internaute dont la machine est lente le sait. Il n’en voudra donc pas spécialement au site s’il n’est pas plus rapide que les autres.

Par contre, il est possible d’influer sur de nombreux paramètres :

  • Avoir un template léger et une homepage qui ne dépasse pas les 600/700 Ko
  • Charger rapidement des éléments visuels, le temps que le reste arrive
  • Les fonctions lourdes en temps de chargement doivent être envoyées à la fin
  • Le site doit être optimisé (la taille des images, des fichiers etc…)
  • L’hébergeur doit avoir un bon peering vers les fournisseurs ADSL (liens rapides avec les autres FAI)
  • Il faut vérifier que des inclusions de codes ou contenus hébergés ailleurs ne ralentissent pas le chargement
  • La bande passante doit être suffisante pour ne pas faire de goulot d’étranglement
  • Les serveurs de l’infrastructure, tous, du Rproxy à la base de données en passant par le frontal web doivent avoir une puissance suffisante
  • Les réglages optimaux en fonction de la topologie du site et de sa fréquentation doivent être appliqués sur tous les éléments et services participant à l’hébergement du site
  • Etc…

écrit par Philippe Humeau

mar 19

Avant toute chose, le Wiki a été mis à jour sur la partie dimensionnement des infrastructures Web. Ca se passe ici, si vous voyez des erreurs, n’hésitez pas à corriger.

Alors, où en est-on sur le front des performances ?

Eh bien si vous avez mis en place les optimisations qui sont recommandées, celles que l’ont vous a expliqué chez Fragento ou ici, celles que l’on va vous exposer dans les prochains posts, bref si vous faites les choses correctement, vous pouvez atteindre de 200 à 800 sessions « Magento connectées » par core (coeur) de vos processeurs récents.

Mais avant de parler des optimisations en elles mêmes, il faut avoir des moyens de comparer, des unités et des repères communs. Je vous propose d’adopter des « S.M.C » comme unité.

S.M.C ?

En premier lieu « Sessions Magento Connectées », qu’est-ce que cela peut bien représenter… ?

Déjà, on va réduire le nom à SMC pour éviter de trimbaler 5 lignes. On peut prendre de nombreux points de repères différents pour estimer la charge : les sessions apache, les Visiteurs Uniques (V.U) journaliers, horaires, le nombre de page vues, etc… Alors pourquoi choisir les SMC ?

Les SMC cela reste un indicateur pertinent car c’est Magento qui mesure cette valeur. Elle peut donc être utilisées dans d’autres contexte, pour faire d’autres calculs mais surtout elle est mesurée partout de la même façon, ce qui est important pour avoir des repères. Comme c’est Magento qui la mesure, on travail tous sur la même valeur.

Comment les récupérer ? Avec une requête SQL en base de données tout simplement :
select count(*) from log_visitor where ADDTIME(utc_timestamp(), -1500) < last_visit_at;

Cela nous donne les sessions ayant eu une activité lors des 15 dernières minutes. C’est très proche de ce que l’on a dans le backoffice. Une dataquery et un script bash plus tard,

On en fait un beau graphique pour les clients dans Cacti ou avec RRD, MRTG etc… :
Graph SMC
Là, par exemple, on voit un mailing. Monté en charge progressive du nombre de SMC pour atteindre les 1200 vers 18H00. Ca se corrèle bien avec le graphique d’utilisation des cores :

Graph Core

On 4 cores utilisés pour 1200, donc 300 utilisateurs par core, en l’occurence ce sont des AMD Shanghai 2374 à 2,3 Ghz. Comme ce sont des quad cores, on utilise un processeur complet. Évidemment on ne peut pas se permettre d’avoir tous les cores à 100% donc les autres processus Linux tournent sur un autre core dédié d’un autre processeur. Coté base de données, ca glandouille gentillement :

Graph core DB
Il faut lire 0,2 core (200 milli). Ceci étant ce site spécifique sollicite peu la base de données donc ce n'est pas représentatif non plus.

Tester les performances, tests de charge & Benchmark !

De nombreux outils existent, qui mesurent différentes choses. En test de charge purs, on a par exemple Load runner, Apache bench, Opensta etc… Coupler tout cela à des analyseurs de code ou de requêtes SQL (comme la console Mysql enterprise par exemple) permet d’optimiser le code mais ce n’est pas le sujet de ce post et Gilles nous fera peut être un petit article là dessus.

Non, ce qui nous intéresse ici, c’est d’évaluer le nombre de SMC que l’on peut servir dans de bonnes conditions avec la plateforme que l’on aura préparé. Pour cela, load runner et Opensta sont de bons outils. Apache bench n’est pas très adapté sincèrement car son test est toujours le même, donc avec la chaine de cache, à la fin de ces 2000 itérations, il vous sort joyeusement 250 000 connectés :)

Opensta permet de définir des scénarii de tests et d’en jouer plusieurs, de front, à suivre, plusieurs fois les mêmes etc… Le soft tourne sous Windows, il est gratuit et opensource. On peut le trouver ici et même s’il n’est plus entretenu, il fonctionne bien et fait le boulot demandé.

Le but ici n’est pas de faire un manuel ou un howto d’opensta mais globalement d’expliquer ce qui représente de bonnes circonstance de tests, tout au moins réaliste. Ce que je fais, en général, c’est que je demande à mes clients, c’est de réaliser entre vingt et trente scénarii classique de surf. On enregistre un très simple de la personne qui vient sur la home et se déconnecte, un autre ou il fait une recherche un autre ou il clique de produit en produit, etc… Le plus le mieux mais également, le plus logique le mieux !

Le scénario de connexion à la home puis déconnexion, on va le jouer 25% du temps, puis celui du parcours de produit 1, le 2 et aussi les recherches. On mixe le tout savamment et on demande à plusieurs scénarii de se jouer sur le site. Trois qui surf, des connexions déconnexions sur la home, deux recherches en même temps etc… A la fin, on regarde les performances affichées par l’interface d’Opensta et celles collectées dans Cacti. On corrèle les graphs, on analyse et on arrive à estimer la charge que peux tenir un système ! En laissant tourner les scénarii un moment, le graph sera réaliste et on saura dire combien de S.M.C peut faire tenir un core standard.

La suite est un jeu d’enfant, on prend le nombre de V.U prévu en pic, on déduit le nombre de S.M.C que l’on doit pouvoir encaisser et on divise par la performance unitaire d’un Core. On sait alors combien de core on doit mettre en place et donc combien de processeurs !

Bon si une bonne âme veut bien écrire un tuto/howto sur Opensta, je passe mon tour pour le moment et je vous laisse juste en compagnie de deux shoots d’écran, le modeler et le commander :

opensta-commander

On définit son scénario dans le modeler ci-dessous, on planifie dans le commander ci-dessus, et on a un autre module qui collecte et affiche les statistiques.

opensta-modeler

Et voila !

écrit par Philippe Humeau \\ tags: , , ,

mar 16

Bon j’en ai un peu marre du sujet « sécurité Magento » pour le moment. On en a beaucoup parlé, on a apporté des idées et des solutions mais j’aimerai repartir sur autre chose. C’est vrai quoi, j’ai fait 10 ans de test d’intrusion, pour me changer les idées, je pars sur du web commerce, un petit retour au système & réseau, bref on s’aère le neurone et là, hop, XSS, CSRF etc…

Donc, aujourd’hui : les inclusions de contenus tiers !

Un petit schéma pour aider à comprendre (quoique… J’ai jamais été très fort en dessin. J’ai été en classe de dessin parce que la plus belle nana du collège faisait dessin, pas réellement pour mon talent en fait). Bref, je m’égare, donc ci-dessous, un site standard, au milieu. Au dessus un bandeau de pub qui vient d’une régie publicitaire, à droite un flux RSS et en bas, c’est de l’invisible, ce sont des inclusions dans le code source des pages.
Lire la suite »

écrit par Philippe Humeau \\ tags: , ,

mar 13

Ce qui est intéressant quand on fait des tutoriels c’est qu’on s’aperçoit que l’on a soit même mal appliqué les astuces que l’on va énoncer.

Je voulais vous faire un petit tutorial sur comment optimiser un peu les pages en elles-mêmes, et finalement on va commencer par quelque chose de plus basique la compression des pages.

La première étape que je vous propose, c’est de télécharger pour ceux qui ne le connaissent pas encore un plugin pour firefox nommé Yslow qui nous donne de nombreuses informations sur l’optimisation de votre site. Ce plugin développé par Yahoo fait parti d’un ensemble de bonnes pratiques pour optimiser le temps de chargement de vos pages. Vous pouvez en retrouver la liste (en anglais) ici : http://developer.yahoo.com/performance/rules.html#cdn

Et en complément quelques idées supplémentaires sur leur blog de développement:
http://developer.yahoo.net/blog/archives/2008/03/yahoos_latest_p.html

Le premier onglet de ce plugin « Performance » nous donne des indications sur le respect de votre site de ces bonnes pratiques. Chaque élément est noté entre A et F et nous donne une idée des points que l’on a pu oublier, comme par exemple activer la compression gzip sur le serveur (bien que la note totale -souvent F- ne présente pas beaucoup d’intérêt car certaines règles sont difficiles à mettre en pratique).

On observe d’ailleurs que Magento respecte naturellement nombres de ces règles (une bien connue maintenant étant la minification des js).

performance

Ce qui nous amène au deuxième onglet, l’onglet « Stats », celui-ci permet d’obtenir le poids total de votre page, ainsi que la répartition du poids entre les différents éléments (images, css, flash, html) ainsi que le poids de votre page une fois que les éléments ont été chargé une première fois et sont dans le cache du navigateur.

yslow_stats

On voit ainsi dans cet exemple la différence de poids que l’on peut avoir entre une page d’accueil avec ou sans la compression gzip. Je pense que je n’ai pas besoin de vous expliquer l’intérêt d’économiser 200Ko de trafic pour chaque internaute qui chargera votre page d’accueil.

Enfin l’onglet « Components » nous permet d’avoir le détail pour chaque élément son poids (avant et après compression gzip), comme l’onglet Net (Réseau en français) du plugin Firebug, on peut voir en rouge les éléments qui n’ont pas été chargés ainsi que le temps de chargement de chaque élément. Cet onglet est intéressant puisqu’on peut classer les éléments par poids. On peut ainsi s’apercevoir qu’on a des images qui mériteraient une compression jpg plus forte, ou qu’un flash mériterait d’être optimisé (voir déplacé ou remplacé par quelque chose de plus léger si par exemple il est sur une la page d’accueil d’un site à fort trafic).

components

J’arrive à mon deuxième point, la compression gzip. En complément du plugin Yslow ce lien http://www.whatsmyip.org/mod_gzip_test/ permet de vérifier immédiatement que la compression est bien activée pour une url donnée.

Pour activer la compression gzip cela suppose que le module apache adéquat soit chargé (mod_gzip qui se nomme maintenant mod_deflate), je vous laisse vous tourner vers votre hébergeur ou google pour vérifier que ce module est chargé.

Ensuite quand le module est chargé, il faut également que les règles apache correspondantes aient été chargées, chose qui n’aura pas toujours été faite quand on vous livre un serveur. On a alors toutes les règles nécessaires dans le fichier .htaccess de notre bon vieux magento qu’il suffit de décommenter :

############################################
## enable resulting html compression

php_flag zlib.output_compression on

############################################
## enable apache served files compression
## http://developer.yahoo.com/performance/rules.html#gzip

# Insert filter
SetOutputFilter DEFLATE

# Netscape 4.x has some problems…
BrowserMatch ^Mozilla/4 gzip-only-text/html

# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip

# MSIE masquerades as Netscape, but it is fine
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Don’t compress images
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary

# Make sure proxies don’t deliver the wrong content
Header append Vary User-Agent env=!dont-vary

(On peut évidemment appliquer directement ces règles dans le httpd.conf d’apache quand on sait ce que l’on fait).

Attention, si l’on transfert du Zip, le « php_flag zlib.output_compression on » va poser problème me remonte un lecteur !

écrit par Olivier \\ tags: , ,

mar 12

Bonjour à toutes & à tous,

Je suis content de revenir parmis vous pour discuter d’un sujet qui a refait l’actualité en mon absence semble t’il : Magento & la sécurité.

Après une belle vague de 3 Cross Site Scripting (XSS) à laquelle nous avons essayé d’apporter des solutions avec Gabriel, une nouvelle faille de type CSRF a été révélée, un peu sauvagement et un peu tôt visiblement.

En général, dans le monde des experts sécurité, on évite de publier une vulnérabilité avant d’avoir prévenu l’éditeur du produit et avant de lui avoir donné le temps réagir. Un mois est une valeur qui n’a rien de conventionné mais qui est communément accepté comme le « minimum ». Le soucis c’est que quand une faille affecte ™Windows©, ©Mic®osoft™ peut déployer un patch correctif par son système automatisé de mise à jour.

Pour un site Web commerçant c’est un peu plus complexe. On ne fait pas une montée de version comme ca, du jour au lendemain. Déjà même pour ce blog WordPress et même en étant moi même un IT, j’ai 8 extensions à mettre à jours et je ne le fais pas par crainte de planter le blog. Alors que dire pour un site de E-commerce.

Donc, quand on a une faille sur Magento, on peut parier que le correctif se fera « à la main » et pas par une montée de version, dans le meilleur des cas. La plupart du temps, le correctif est tout simplement ignoré, on vit avec la faille en espérant que personne ne la remarque.

Revenons à nos moutons : le Cross Site Request Forgery aka « CSRF »…

Encore un OVNI pour beaucoup de Web developpers mais une réalité terrain pour les personnes mal intentionnées. La sécurité « Web 2.0 » (chapeau les marketeux) est une chose un peu complexe, il existe de multiples attaques (XSS,SQl injection,anti dns pinning, CSRF, Sop, smuggling, etc…) et un article complet aurait bien sa place à l’avenir sur le sujet.

Dans l’immédiat, il est important de comprendre que la faille vient souvent d’un mauvais usage (ou d’un oubli d’usage) de Zend. Zend est propre et filtre correctement tout un tas de chose qui peuvent compromettre un site, mais quand on ajoute « à la main » du code, sans appeler les routines natives Zend, on perd cette protection. Attention, ce qui vaut ici pour Varien vaut aussi pour les développeurs Web qui enrichisse un site de E-commerce de leurs propres créations. Zend protège mais ne fait pas tout non plus contre toutes les attaques…

Pour se protéger, il existe des méthodes simples, à mettre en place systématiquement (à mon sens). Dans un premier temps, les URLs d’admin doivent être obfusquées, cachées, en tout cas difficiles à trouver. Pour se faire, garder le chemin par défaut n’est pas une idée à retenir :)

Dans le fichier qui paramètre cette URL (app/etc/local.xml), on peut modifier la ligne :
<frontName><![CDATA["mettre la fin d'url souhaitée ici"]]></frontName>

Ensuite, comme après chaque manipulation fondamentale, on efface son cache (dans var/cache/)
Si vous ne trouvez pas le frontName, vous pouvez l’ajouter dans des tags <config></config>

C’est une protection de fond et autant, au passage, ajouter celle qui était déjà mentionnée dans l’article sur les correctifs XSS : le htpassword. Comme cela, votre admin est difficile à trouver et ensuite pour y entrer, il faut avoir un premier login/pass… dur.

<LocationMatch “/mettre la fin d’url souhaitée ici” >
AuthUserFile /var/www/htdocs/.htpasswd
AuthType Basic
AuthName “Magento Backoffice Login”
Require valid-user
</LocationMatch>

Je pense qu’on peut aussi ajouter : (j’ai pas testé cependant)
Allow from 111.222.121.212 (remplacer par son IP)
Satisfy Any


Comme ca, on peut soit venir de l’ip ou avoir le mot de passe. Soit l’un, soit l’autre, on peut faire que l’un ou que l’autre. Si on vient de la bonne IP, évidemment, on a pas à taper le mot de passe. Avec ca, finit les XSS ou CSRF sur vos backoffice d’admin.

Ceci étant, ça fait deux série de vulns en 2 semaines, ça veut dire qu’il va falloir passer tout cela au crible, je suppose aussi que des experts sont déjà sur le coup et en ont déjà communiqué à Varien mais attendent un mois avant de les publier.

Allez, demain ou lundi on parlera de ces inclusions de contenus qui ralentissent les beaux sites web que vous mettez en place :)

écrit par Philippe Humeau \\ tags: , , , ,