Découvrons Modernizr

Nous l’avons vu dans un précédent article, la propriété CSS @supports permet au moteur de rendu de tester la présence ou non d’une fonctionnalité. Nous avons cependant noté qu’elle n’était pas supporté par Internet Explorer, ce qui limite son intérêt dans l’immédiat. Une autre solution pour tester le support d’une fonctionnalité est la librairie Modernizr.

Modernizr est une librairie JavaScript qui permet de détecter le support de différentes fonctionnalités CSS et JS afin de créer des règles ou des fonctions spécifiques en fonction du support ou non d’une fonctionnalité.

Pour cela, on commence par se créer un build personnalisé en fonction de nos besoins en cochant les fonctionnalités que l’on souhaite détecter : modernizr.com/download. On peut ainsi détecter si une propriété CSS est utilisable sur le navigateur, si un événement est disponible, si une balise HTML est reconnue, … On peut également inclure HTML5 Shiv qui active les balises HTML5 dans les vieux navigateurs (Internet Explorer 6-9, Safari 4, Firefox 3, …).

Exemples d’utilisation :

Il existe beaucoup d’autres méthodes utilisables. Elles sont toutes visibles dans la documentation. Il est également possible d’ajouter ses propres méthodes de détection.

Sources :

Introduction à fail2ban

« fail2ban lit les logs de divers services (SSH, Apache, FTP…) à la recherche d’erreurs d’authentification répétées et ajoute une règle iptables pour bannir l’adresse IP de la source. » (source : doc.ubuntu-fr.org)

Par défaut, fail2ban applique un blocage de 10min après 6 tentatives en 10min.

Pour configurer ses « prisons », il faut éditer le fichier /etc/fail2ban/jail.conf.

Exemple :

  • ignoreip : les IP 127.0.0.1 et 8.8.8.8 sont ignorées pour tous les ports
  • fintime : fail2ban remonte 1 heure dans les logs
  • bantime : les ips sont bloquées 24 heures
  • enabled : pour activer/désactiver une prison
  • port : le/les port(s) correspondant(s) à la prison. Il faut penser à mettre les numéros de ports s’ils ont été modifiés. Par exemple, si on passe ssh sur le port 2212, il faut mettre 2212 à la place de ssh.
  • filter : le filtre à appliquer. La liste des filtres est dans /etc/fail2ban/filter.d. Il est possible d’en créer soi-même.
  • logpath : le chemin du fichier de log à analyser
  • maxretry : le nombre maximum de tentatives par une IP dans le laps de temps findtime

Il est également possible d’envoyer un mail dès qu’une adresse IP est bannie. Pour cela, il faut ajouter les lignes suivantes :

  • destemail définit le destinataire du mail
  • action définit l’action à effectuer lors d’un blocage. action = %(action_)s est l’action par défaut, elle se contente de bloquer l’IP. action = %(action_mw) envoie un mail à chaque bannissement. action = %(action_mwl) envoie un mail avec les logs.

Une fois la configuration modifiée, il faut la recharger :

Pour voir le nombre de prisons lancées :

Et pour surveiller le fonctionnement d’une prison :

Les filtres qui me paraissent importants à mettre en place sont les suivants :

  • ssh
  • apache-phpmyadmin
  • apache-noscript
  • anti-w00tw00t

Sources :

Le responsive côté serveur

Conférence de Rémi Grumeau à la Kiwi Party 2015.

Le principe : utiliser une base de données ou une API faisant la correspondance entre user-agent et viewport afin de proposer un layout différent selon le périphérique.

Il faut toutefois garder une gestion « mobile-first » dans le cas où le périphérique n’est pas connu et également conserver des tests côté client pour certaines fonctionnalités comme la géolocalisation, le mode online/offline, …

Une idée intéressante est de générer les images à la volée en fonction du viewport. Le site resrc.it permet de faire cela.

Toutes les vidéos de la Kiwi Party sont à retrouver sur Vimeo : vimeo.com/search/sort:latest?q=kiwiparty

Les pseudos-classes CSS

Il existe de nombreuses pseudo-classes en CSS. Le site developer.mozilla.org en a d’ailleurs fait une liste. Celles qui peuvent le plus nous intéresser sont :

  • :visited et :link qui permettent de cibler les liens déjà visités ou pas encore visités.
  • :hover, :active et :focus, qui ciblent un élément survolé, activé (au moment du clic) ou ayant le focus.
  • :target qui sélectionne l’élément ayant l’id passé dans l’url. Thomas avait expérimenté cette pseudo-classe dans un précédent article.
  • :checked qui cible les éléments cochés (radio bouton ou checkbox) ou sélectionné (select liste)
  • :valid, :invalid ou :required, bien pratique pour différencier les éléments de formulaire obligatoire et mal remplis.
  • :first-child, :first-of-type, :nth-child() pour cibler précisément les éléments du DOM
  • :not() cible les éléments qui n’ont pas la classe passée en paramètre par exemple

J’ai utilisé ces propriétés sur l’exemple suivant : codepen.io/maattt/pen/ZpvQXd

À noter que la pseudo-classe :hover est activée au moment du clic sur certains mobiles (Android, iPhone) mais pas sur tous (Windows Phone). Il est donc conseillé de la coupler avec la pseudo-classe :focus (source).

Rails 5 : Nouveautés syntaxiques

Avant sa sortie, nous avions fait le point sur les principales nouveautés de Rails 5 : quoi de neuf sur Rails 5 avant sa sortie finale ?.

Après avoir développé avec pendant quelques semaines, voici nos premiers retours concernant les nouveautés de syntaxes impliquées par Rails 5.

Nous avions également relevé quelques nouveautés lors de l’écriture de tests : Rails 5 & tests : nouveautés et astuces.

Deprecated

Plusieurs méthodes sont dépréciées :

  • before_filter est deprécié et remplacé par before_action. Il sera supprimé en Rails 5.1.
  • render text: "hello world" est remplacé par render plain: "hello world".
  • render mon_path est remplacé par render file: mon_path.
  • render nothing: true doit être remplacé par autre chose selon le contexte (render plain: "ok" pour les crons ou une des deux alternatives)
  • Les fichiers SASS sont suffixés .scss et plus .css.scss.

belongs_to requis par défaut

Par défaut, un belongs_to posséde un attribut required à true. Cela implique que l’objet associé doit obligatoirement exister pour que l’objet courant soit créé.

Par exemple :

implique que le questionnaire est persistant quand on instancie une question. Cela peut poser problème lorsqu’on utilise les nested_attributes et qu’on enregistre en même temps le questionnaire et les questions associées. Il faut alors passer l’attribut required à false (ou optional à true)

where.or

Les ActiveRecord::Relation possèdent une méthode or :

Sources :

Rails – Utiliser les URL Helpers dans les vues des mails

En Rails, quand on crée les templates d’emails, il peut être intéressant d’utiliser les « URL Helpers » plutôt que d’écrire manuellement ces URL dans la vue (surtout que les URL en production diffèrent de celles de développement).

Par exemple, si on a un contrôleur articles avec une action index, il existe un helper articles_url qui permet d’accéder à cette action. Ainsi, si on veut faire une ancre vers cette action, on écrira :

plutôt que :

pour ne pas avoir à modifier l’url https://mon-url.com à chaque fois qu’on passe de développement à production.

Pour utiliser ces URL Helpers dans les vues des emails, l’application doit connaitre le nom de domaine qui l’héberge. Pour cela, il faut ajouter aux fichiers de config d’environnements :

Rails 5 & tests : nouveautés et astuces

Nouveautés

Test des contrôleurs

En Rails 5, la méthode qu’on utilisait pour tester les contrôleurs est dépréciée en faveur de l’utilisation de « hash parameters ».

Utilisation de assigns

La fonction assigns qui permet de récupérer une variable @variable du contrôleur a été retirée de la gem ‘rails’ en version 5. Pour pouvoir l’utiliser, il faut inclure la gem ‘rails-controller-testing’ dans le Gemfile.

Astuces

Changer le message d’une failure

Récupérer plusieurs fixtures dans un tableau

Test des flash notice

Recharger un objet après qu’il ait été mis à jour

Doc : guides.rubyonrails.org

Rails : exécuter les tests

Exécuter tous les tests

Exécuter les tests d’un répertoire

Exécuter les tests d’un fichier

Exécuter un test en fonction de son nom

Exécuter le test d’une ligne

Doc : guides.rubyonrails.org

Rails – Variables d’environnement & Figaro

En rails, depuis quelques versions et notamment en rails 5, lorsqu’on génère une nouvelle application, on a vu apparaître l’appel à ce type de variable : ENV['APPLI_DATABASE_PASSWORD'], ENV['DATABASE_URL'], ENV["SECRET_KEY_BASE"]. Ces variables de configuration sont des variables privées qu’il ne faut pas partager, notamment dans un projet github.

On peut alors se demander où et comment définir ces variables.

Solution 1 : définir des variables d’environnement UNIX

Pour cela, il suffit d’ajouter au fichier ~/.bashrc (ou ~/zshrc si on utilise zsh) :

Cette variable d’environnement sera alors accessible dans l’application Rails : ENV['MA_VARIABLE'].

Solution 2 : utiliser la gem Figaro

Utiliser les variables UNIX peut vite devenir contraignant. C’est la gem Figaro est intéressante. Elle génère un fichier config/application.yml dans lequel on stockera nos variables d’environnement.

Exemple :

Source : http://railsapps.github.io/rails-environment-variables.html

Spécifier le chemin local d’une gem dans le Gemfile

Dans le Gemfile d’un projet Rails, la source est précisée en haut du fichier :

Il est également possible de préciser une source différente pour une gem :

Mais on peut aussi spécifier un chemin local :

Ainsi, on peut tester une gem en cours de développement sans la publier.

Plus d’infos sur le Gemfile : bundler.io