Les origines d’Opengento 

J’ai relu hier un article parlant de sortir de sa zone de confort pour combattre ses peurs, ce qui m’a donné envie de vous raconter l’histoire de la MageConf et d’Opengento.

C’était en Juillet 2013, un mail est parti à tous les développeurs Magento Français que je connaissais :

Je vous contacte pour faire avancer cette idée qui me trotte dans la tête depuis un certain temps déjà, celle d’organiser une conférence pour les dev Magento par les dev Magento. L’objectif est principalement d’animer la communauté et de partager notre expérience, mais pas de faire de la promotion.
Je souhaiterai mettre en place une organisation relativement ouverte, ou chacun participe à titre personnel. L’événement sera sponsorisé par des entreprises (4 à 6 max) qui souhaitent se voir associer à la conférence mais il n’y aura aucune autre forme de promotion. Les confs et tables rondes parleront de code, d’organisation, d’architecture, de gestion de projets, etc…

 

Derrière cet email se cache l’une de mes vieilles peurs… celle de parler en public.

Impossible de prendre la parole dès qu’il y avait plus de 5 personnes en réunion, alors prendre un micro, monter sur une scène, voir parler devant une caméra, c’était mission impossible.

Mais un jour cela a commencé à poser problème. C’était pour l’organisation d’un Bargento. En tant qu’organisateur, je pouvais facilement faire une conférence, mettre en avant mes compétences, et puis je devais quoi qu’il arrive prendre la parole devant plusieurs personnes, avant mais surtout le jour J, ce qui m’était m’était difficile voire impossible.

Aucun souci pour discuter en tête à tête, je me réfugiais là-dedans…

Et je me suis rendu compte qu’il fallait que je le fasse. Il fallait que j’apprenne à parler en publique, c’était trop important pour Boutik Circus.

J’aurais pu y aller tranquillement, m’entraîner devant mon miroir, en me rasant, me répéter « Nicolas, un jour tu sera président »…

Mais cela n’est pas trop ma façon de faire. J’ai choisi une méthode où je ne pourrais pas fuir, et où personne ne me jugerait. J’ai organisé ma propre conférence, la MageConf. Et j’ai envoyé un email, pour commencer.

Et puis il y a eu des retours, des personnes motivées, et je me suis retrouvé face au mur que j’avais moi-même mis en place 🙂

Je me souviens de mes premiers mots pour cette MageConf « Bonjour, je suis désolé c’est la première fois que je parle en public ». Puis la peur est partie. Ciao.

J’ai depuis pu faire plusieurs conférences, sur Magento, sur l’entrepreneuriat, sur ma façon de voir le nomadisme, et je prends toujours autant de plaisir à partager mon expérience !

Et puis cette expérience m’a dépassée, puisque à la suite de la MageConf, on a créé ensemble Opengento dont j’ai été le premier président, l’association qui regroupe et qui anime les développeurs Magento en France. Petit à petit, cela porte ces fruits, comme ce week-end à Toulouse ou l’on se retrouve chaque année, toujours avec autant de plaisir, ou ce channel Slack très actif où les meilleurs développeurs Magento français s’échangent leurs bons tuyaux 😉

Bref, c’est bien de l’autre côté de la zone de confort qu’on avance et qu’on fait de belles choses. Et quelle bonne idée d’envoyer ce mail 🙂

Creer un webhook pour Gmail

Présentation du projet

Le besoin est né d’une idée simple : pouvoir notifier mon application en Nodejs lorsque je reçoit un nouveau message dans ma boite Gmail.

Concernant l’API Gmail, je vous invite à suivre la documentation officielle : https://developers.google.com/gmail/api/v1/reference/

Pour cela nous allons utiliser la messagerie Pub/Sub de Google Cloud, celle ci apporte un moyen rapide et sécurisé de s’abonner à des topics, vous avez la possibilité de faire du point à point ou envoyer en multicast. Je vous invite à découvrir ce middleware orienté cloud à cette adresse : https://cloud.google.com/pubsub/docs/overview.
Ensuite rendez-vous dans la section Pub/Sub où nous allons créer un Sujet :

 

Voici un petit schema sur le concept de subscriber / publisher qui vous aidera à appréhender un peu mieux le workflow de Pub/Sub :

Reste à notifier Gmail que l’on souhaite qu’elle publie un nouveau message lorsqu’un nouveau mail arrive. Voici un petit schéma expliquant les différentes étapes de notre projet :

Into ze code

Configuration Pub/Sub

Si vous n’avez pas de compte GCloud, commencez par en créer un https://cloud.google.com/.
Ensuite rendez-vous dans la section Pub/Sub, où nous allons créer un sujet :

Donnez un nom à votre sujet puis cliquez sur CREER. Ensuite nous allons créer un abonné qui sera l’url de notification de notre application, une fois que vous avez cliquer sur Nouvel abonnement, donnez un nom à votre abonnement et choisissez Envoyer vers une URL de point de terminaison et mettez y votre URL.
Attention, l’url sera obligatoirement en https, si vous obtenez une erreur, c’est que vous n’avez certainement pas autorisé le domaine, dans ce cas rendez-vous dans la section API et services puis onglet identifiants, là vous n’aurez plus qu’à suivre la procédure pour ajouter votre domaine.
Une fois votre abonnement créer, vous pourrez tester en publiant un message depuis votre sujet.

Gmail -> Pub/Sub

Si on regarde du coté Gmail, si l’on veut pouvoir broadcaster une notification vers Pub/Sub dans ce cas il faut lui dire 2 choses :

  • Sur quelle action
  • Quel sujet Pub/Sub envoyer

Pour commencer, nous allons utiliser la fonction watch() de l’API Gmail.

Voici un exemple avec ce script python :

 

watch.py

from __future__ import print_function
import httplib2
import os

from apiclient import discovery
from oauth2client import client
from oauth2client import tools
from oauth2client.file import Storage

try:
import argparse
flags = argparse.ArgumentParser(parents=[tools.argparser]).parse_args()
except ImportError:
flags = None

# If modifying these scopes, delete your previously saved credentials
# at ~/.credentials/gmail-python-quickstart.json
SCOPES = 'https://www.googleapis.com/auth/gmail.readonly'
CLIENT_SECRET_FILE = 'client_secret.json'
APPLICATION_NAME = 'Gmail API Python Quickstart'
def get_credentials():
"""Gets valid user credentials from storage.

If nothing has been stored, or if the stored credentials are invalid,
the OAuth2 flow is completed to obtain the new credentials.

Returns:
Credentials, the obtained credential.
"""
home_dir = os.path.expanduser('~')
credential_dir = os.path.join(home_dir, '.credentials')
if not os.path.exists(credential_dir):
os.makedirs(credential_dir)
credential_path = os.path.join(credential_dir,
'gmail-python-quickstart.json')

store = Storage(credential_path)
credentials = store.get()
if not credentials or credentials.invalid:
flow = client.flow_from_clientsecrets(CLIENT_SECRET_FILE, SCOPES)
flow.user_agent = APPLICATION_NAME
if flags:
credentials = tools.run_flow(flow, store, flags)
else: # Needed only for compatibility with Python 2.6
credentials = tools.run(flow, store)
print('Storing credentials to ' + credential_path)
return credentials

def main():
"""Shows basic usage of the Gmail API.

Creates a Gmail API service object and outputs a list of label names
of the user's Gmail account.
"""
credentials = get_credentials()
http = credentials.authorize(httplib2.Http())
service = discovery.build('gmail', 'v1', http=http)
request ={'labelIds': ['INBOX','UNREAD'],'topicName': 'projects/[VOTRE PROJET]/topics/[VOTRE SUJET]'}
service.users().watch(userId='me', body=request).execute()
if __name__ == '__main__':
main()

Pensez bien à remplacer le topicName avec le bon nom de sujet.
Sachant que ce mode d’observation a une durée de vie de 7 jours, il sera souhaitable de l’automatiser via une tâche cron par exemple.

Sécurité avant tout, sécurisez vos caches Magento!

La sécurité d’une boutique Magento, dépend notamment de la sécurité liée au droits d’accès à certains dossier/fichiers.

Nombre de boutiques sont vulnérables, sans même le savoir.

En effet, le dossier var/cache, qui normalement ne peut être lu que depuis le serveur, par le serveur, peut, en cas de mauvaise manipulation se retrouver en libre accès (lecture), et donc être sauvagement enregistré dans les résultats Google.

A partir de ce moment là, la sécurité de votre boutique est compromise !

Les informations stockées dans les fichiers de cache, correspondent à la configuration même de votre boutique, nous y retrouvons donc :

  • Les informations d’accès à votre base de données (host / user / password)
  • La configuration de votre boutique
  • Les informations d’accès à votre/vos comptes API (si tant est que vous en utilisiez).

Dans le cas d’un google leak (fuite sur Google), il est fortement conseillé de :

  • Sécuriser vos accès Mysql, changer de mot de passe, modifier votre user si nécessaire, et mettre en place des actions de restriction de connexion via IP.
  • Modifier les clef et pass API, afin de sécuriser l’accès aux données.

Un petit cas pratique ? en voici un !

Il nous faudra pour ceci :

  • un accès internet, et rien d’autre 😉

Google permet de rechercher de manière très spécifique certains types de fichiers, certains éléments dans un URL, certains élément présents dans le texte d’une page, voir même de combiner le tout.

C’est ce que l’on appelle les dorks Google. (Un autre billet sera fait en détaillant certaines de ces dorks).

👮👮 INFORMATION IMPORTANTE : 👮👮
Ce qui suit à été effectué à des fins pédagogique, il est formellement interdit de hacker, tenter de pénétrer dans un système informatique qui n’est pas le notre, sous peine de poursuites judiciaires !

Voici notre protocole :

1/ On va rechercher sur google , les sites disposant d’un leak sur le dossier de cache qui est var/cache/

2/ Parmi ces « cibles » potentielles, nous allons chercher celles qui disposent d’un accès au fichier qui contient notamment les accès à la base de données (Je ne publierais pas ici le nom du fichier incriminé)

Faille de sécurité par accès au cache Magento - Les ingnorants
Magento – Google Leakage of cache metadatas – Magendium

3/ On recherchera dans ce fichier les informations qui nous intéresse…

4/ Au choix, soit [notre choix] on contact le propriétaire du site pour lui faire part de cette faille de sécurité , soit vous tentez d’accéder au store de manière frauduleuse…

Dans tout les cas, la correction est facile à mettre en œuvre si votre boutique est compromise.

Chez Magendium, nous apportons notre soutien et notre savoir faire dans la résolution de ce genre de failles de sécurité.

Faut-il migrer sous Magento 2 ?

C’est la question du moment chez nous, nos clients, et dans la communauté.

Pour les projets d’envergure qui débutent ou migrent d’une autre plateforme, il est évident qu’il faut commencer sous Magento 2, la question ne se pose plus aujourd’hui.

Pour les nouveaux « petits » projets nécessitant peu de personnalisations, il peut être encore intéressant de se lancer sous Magento 1, la base d’expérience, de modules et de thèmes disponibles font qu’on peut aller très vite, ce qu’on ne pourra pas faire sous Magento 2. En cas de réussite du projet, la migration vers Magento 2 pourra être faite dans 2 ans, après la fin du support officiel.

Par contre la question de la migration d’un projet sous Magento 1 vers Magento 2 est beaucoup plus complexe…

J’ai voulu écrire cet article suite à un coup de fil cette semaine avec un prospect qui venait nous voir pour migrer son site sous Magento 2 « parce que nous avons des problèmes de performance »…

Ceux qui ont déjà développé sous Magento 2 savent…

Magento 1 est bien plus performant que Magento 2… je sais que la communication de Magento Inc ne va pas dans ce sens, mais il est intéressant de comprendre pourquoi. Dans sa nouvelle version, Magento a ajouté des niveaux de caches et le support de PHP7, qui est beaucoup plus rapide. On peut donc s’attendre a de meilleurs résultats avec Magento 2.

MAIS, c’est un peu un cache misère pour le coup, le core a pris beaucoup de lourdeurs (pour la bonne cause, mais lourdeurs quand même), et une fois ces caches désactivés, les performances deviennent vraiment mauvaises au point de devenir très compliqué à gérer pour les développeurs qui passent leur journée sans cache…

Si il n’y a effectivement pas de soucis en production pour les boutiques en ligne (voir notre démo Magento 2), Magento 1 peut bénéficier très facilement de ses améliorations de cache. Le support de PHP 7 est désormais assuré, et les modules permettant d’améliorer le cache ne manquent pas (Varnish / FPC / Etc…).

La situation peut changer dans le futur mais Magento 1 reste aujourd’hui bien plus rapide et vouloir migrer pour des problèmes de performances c’est se tromper de problème: les ralentissements qui ont été introduit dans le site de ce prospect et l’optimisation de ses performances.

Plus le temps passe, plus Magento 2 s’améliore. Il ne faut pas oublier que la première version Magento ne fut vraiment stable qu’à sa version 1.3… Votre boutique en ligne n’est pas un smartphone, et vouloir à tout prix la dernière version à la mode n’est pas forcément une bonne idée.

Il me semble pertinent de migrer en cas de développements massifs, autant les faire tout de suite sous Magento 2 plutôt que d’avoir à tout refaire plus tard, mais si rien ne presse, prenez votre temps, ça vous coûtera moins cher et vous bénéficierez de plus d’expériences!

 

Faut-il passer son Magento en HTTPS?

A tort ou à raison, Google & Mozilla poussent désormais tout le monde vers le HTTPS, et de plus en plus fort…

Pour rappel, cette technologie permet de chiffrer les données et les communications de poste à poste, en certifiant les interlocuteurs. C’est le fameux cadenas vert qui est normalement utilisé pour les transactions par carte bancaire.

On voit bien l’intérêt pour un paiement, mais peut-être que vous ne voyez  pas un grand intérêt à crypter votre fiche produit, puisqu’elle est publique…

En réalité, la question n’est pas tellement là.

Google veut que l’on passe en HTTPS, et s’en donne les moyens. Pourquoi le fait-il? C’est visiblement plus politique que pratique pour le coup. Chiffrer toutes les communications améliore globalement la sécurité, mais c’est aussi un moyen de limiter l’espionnages et la surveillance de masse.

Votre fiche produit est peut-être publique, mais l’identité de la personne qui consulte cette fiche est une donnée privée qui intéresse beaucoup de monde…

Depuis quelques années, tout est fait pour nous faire passer en HTTPS : les certificats sont devenus gratuits, Google promet un avantage pour le référencement des sites l’utilisant, et de plus en plus d’alertes apparaissent sur les navigateurs quand on ne l’utilise pas :

Alors pourquoi tous les sites ne sont-ils pas déjà en HTTPS ?

Parce qu’en réalité, cela n’est pas simple… et nombreux sont ceux qui ont beaucoup perdus quelques plumes en migrant trop vite.

Le problème vient du fait que Google considère que le site en HTTPS est un site différent de celui en HTTP (voir Sécuriser votre site à l’aide du protocole HTTPS).

Il y donc forcément une perte de position temporaire, et il faut correctement mettre en place les redirections pour que les anciennes positions soient bien transmises page à page, le risque étant de tout perdre. Il y a également un risque de duplication de contenu entre les 2 versions.

Concernant le certificat, il faut qu’il soit bien reconnu pour tous les navigateurs ! Il n’y a pas si longtemps, Google mettait des avertissements sur des certificats obsolètes quand Internet Explorer ne reconnaissait pas encore les versions plus récentes…

Et puis il y a les pages des sites qui doivent pouvoir appeler tous les éléments en HTTPS, et non en HTTP, si des liens en dur ont été mis dans le code, il faut identifier les erreurs et tout aller corriger à la main… Sans parler des liens internes qui doivent être mis à jour.

Il y a aujourd’hui des solutions à tous ces problèmes, et il est évident qu’il va falloir y passer rapidement, mais il faut bien mesurer l’ampleur de ce projet !

 

Hébergement Magento – Lancement d’une offre spécialisée MAGENTO

Bienvenue chez Magendium !

Nous sommes heureux et fiers de vous présenter notre nouvelle offre d’infrastructure pour l’hébergement de vos boutiques MAGENTO.

Magendium, c’est une équipe de 6 personnes dont 5 développeurs MAGENTO passionnés aux profils divers, et aux vies variées, qui se lancent dans le grand bain d’une offre d’hébergement MAGENTO audacieuse et performante.

Le grand bain, c’est la vie en mer, pour Nicolas , le fondateur, et c’est l’entrepreneuriat pour le reste de l’équipe qui attrape au vol le ballon qui lui est lancé.

Magendium est avant tout une aventure commune à l’agence spécialisée Magento qu’est Boutik CIrcus, qui souhaite mettre à disposition de ses clients, des serveurs, non seulement optimisés, mais surtout correctement dimensionnés et évolutifs !

En effet, Magendium dispose d’un système de monitoring sur mesure qui permet, de proposer un dimensionnement en fonction de l’utilisation serveur.

Ces optimisations de performances, sont par la suite réalisées en quelques minutes, que ce soit pour une évolution ascendante des performances, ou une évolution descendante de celles-ci.

Toute nos offres disposent de la mise en place d’un certificat SSL Let’s Encrypt, mais pas seulement.

Pour ceux qui le souhaitent également, nous pouvons mettre à disposition dans un délais raisonnable et pour une durée limitée une de nos instances, afin de la tester. (Attention, vous n’êtes pas root, mais c’est une instance dédiée).

Si vous avez des besoins spécifiques, un paquet particulier à installer, une demande qui sort de l’ordinaire, notre équipe de spécialistes, mettra tout en œuvre, pour répondre à vos besoins dans les délais les plus courts possible.

Nous vous souhaitons donc la bienvenue, la bonne arrivée, pour prendre connaissance de nos offres d’hébergement, et y adhérer si vous le souhaitez.

Nous sommes à votre écoute en ces jours de lancement pour améliorer, éclaircir, enrichir, tout point qui vous semblerait utile.

Que cette collaboration soit longue et fructueuse, wish us luck!

Nicolas, Vincent, Julien, Maxime et Camille, de Tourves

Nicolas, à Ibiza !