L’actualité
Cookies/trackers : La date limite de mise en conformité approche !
Vous avez probablement remarqué vous aussi que de nouvelles règles sur la gestion des cookies entraînaient l’apparition de fenêtres de plus en plus grandes et envahissantes sur vos sites préférés. Et bien vous aussi, allez devoir en mettre : la CNIL laisse jusqu’au 31 mars 2021 pour vous mettre en conformité sur les nouvelles règles de gestion des cookies. Et après cela, c’est le strike. Vous trouverez directement sur le site de la CNIL les règles à mettre en place : https://www.cnil.fr/fr/cookies-et-traceurs-comment-mettre-mon-site-web-en-conformite
#actu:focus : Quand l’hébergement français s’enflamme
Merci OVH.
Cette semaine on est obligé de penser à ce magnifique feux de joie. Que faut-il en retenir ? LES BACKUPS et l’importance de vérifier que les backups sont bien stockés à des endroits différents dans le monde !
En tant que Consultant c’est aussi notre devoir de mettre ces sujets sur la table et d’éduquer nos clients sur la sécurisation de leurs données.
Un environnement de développement public sur le net ?
La semaine dernière un de nos consultants à subit les foudres des bots informatiques et à perdu une base de données de dev. Pourquoi ?
Un environnement de développement accessible publiquement était disponible sur le net. Symfony configuré en mode dev ne bloque pas le phpinfo. Résultat : les variables d’environnement de symfony étaient lisibles par des petits bots qui se sont amusés à drop la base de données.
Que puis-je mettre en place pour améliorer la sécurité de mon environnement ?
Vérifier que la commande phpinfo est désactivée, que votre php.ini n’est pas lisible et plus généralement que vos ports soient bien configurés.
Mettre en place un accès VPN si possible
Mettre en place des utilisateurs de BDD avec des droits limités (Exemple : Après avoir fait votre build et fait vos updates de BDD, remplacer le user mysql du .env par un user plus restreint)
Désactiver l’accès distant de votre base de données en public et ne l’autoriser que pour votre serveur, votre vpn et si possible que sur certains utilisateurs.
Restreindre l’accès par localisation à votre serveur. Exemple pour un site de dev en public: il est quasiment sûr que vous n’avez pas besoin d’y accéder depuis un autre pays que la France. Cela réduit drastiquement les bots qui peuvent vous attaquer. Il faut en discuter avec l’équipe Infra. Sur AWS il est possible de mettre en place des stratégies de traffic via
AWS Route53
Mettre en place un module permettant de limiter le trafic d’une même IP. ( Permet notamment de se prémunir des attaques DDOS et de limiter la charge de votre serveur à un trafic plus “réel” ). Sous apache par exemple il y a mod_ratelimit ou mod_qos
Vous pouvez également mettre en place un .htaccess sur votre environnement avec des identifiants ( dédicace au SI ! )
Pour les utilisateurs AWS je vous invite aussi à regarder du côté de AWS SHIELD et AWS WAF pour bénéficier des blacklists AWS mises à jour en temps réel
Webdomadaire
has() : la feature CSS de la semaine
Deep dive dans le CSS4.
Découvrons une nouvelle propriété compatible nulle part. Mais elle est terriblement pratique : n’avez-vous jamais ressenti le besoin d’appliquer un style à un conteneur parent en fonction de la présence d’un enfant en particulier ? C’est ce que vous propose la pseudo-classe :has(), actuellement en working draft. Votre navigateur connaît déjà des propriétés et pseudo-classes CSS 4 ! Ce site permet de les découvrir.
Des animations CSS / JS stylées ?
Les confins de codepen.io.
Je vous propose quelques liens avec du code sources pour réaliser des animations et vous donner quelques idées pour vos projets
Steam inspired game card hover effect
Card Hover Interactions (codepen.io)
Image slider with multiple controls and mobile swipe control (Javascript) (codepen.io)
Animated Tab Bar v.2 (codepen.io)
SVG clip-path Hover Effect (codepen.io)
CSS Search Field Animation (codepen.io)
Voyage Slider | GSAP (codepen.io)
Sliding tabs | CSS transitions only (codepen.io)
Pokemon Card Holo Effect (codepen.io)
Les dossiers
Symfony : cas d’étude – un mode maintenance facile.
On s’est tous ou presque retrouvé à devoir mettre un site en maintenance pour une durée variable. Plusieurs méthodes existent : avoir une ligne à décommenter dans le .htaccess, une branche dédiée à déployer avec le index.php qui redirige tout vers un maintenance.html… Peut-être même avec un filtrage d’IP pour pouvoir en tant qu’admin continuer à consulter le site. Récemment je suis tombé sur une méthode que je trouve assez sympa et qui nécessite peu d’intervention serveur. Ce cas d’étude est sur un site en Symfony 3.4, et complète ce tutorial en ligne, en ajoutant quelques trucs supplémentaires assez sympa, comme la possibilité de vous balader sur votre site pendant que celui-ci est en mode maintenance.
Créer un détecteur de mode maintenance
Le principe est très simple : on va créer un eventListener qui détecte la présence d’un fichier .lock dans le dossier web (public pour symfony 4 et plus) de notre application. Peu importe son contenu. S’il est présent, l’application active le mode maintenance.
Pré-requis
Pour pouvoir utiliser ce mode maintenance facile, il vous faudra un accès terminal à votre serveur avec la permission d’écrire dans le dossier de votre application.
Étape 1 : Config
On va commencer par indiquer à notre application où chercher ce fameux fichier .lock :
Ensuite, on va créer notre listener :
On remarque que notre service prend en paramètre du constructeur notre lockFilePath, du coup on oublie pas de l’indiquer dans le services.yaml, avec les bons tags pour signaler qu’on va écouter l’évènement request.
Qu’est-ce que fait notre listener du coup ? Pour reprendre une célèbre citation de Jamy Gourmaud “Hé bien c’est très simple”, notre eventListener regarde s’il y a un fichier .lock dans le dossier web/ de notre application, et si oui, la réponse à toutes les requêtes sera forcément “Le site est en maintenance”.
Désormais, on peut activer et désactiver le mode maintenance depuis un terminal connecté au serveur :
C’est cool, mais on aimerait une vraie page de maintenance, non ?
Étape 2 : ajoutons du twig
Pas de souci c’est pas bien dur, on va simplement insérer également Twig dans notre event listener. Éditons un peu notre déclaration de service :
Parfait, maintenant on va pouvoir utiliser twig dans notre eventListener :
Ici on est en symfony 3.4, on aura donc mis notre template de maintenance dans app/Resources/views/maintenance.html.twig, mais libre à vous d’ajuster le path. Vous êtes des grand.e.s développeur.euse.s
La cerise sur le gâteau : je suis admin, je fais ce que je veux !
C’est cool ce petit mode maintenance, hein ? Ce qui serait encore plus cool c’est qu’en tant que dev je puisse me balader librement sur le site même quand le mode maintenance est actif. À partir de là, on sort du tuto dont je vous ai mis le lien pour aller dans les ajouts perso.
On va ajouter un filtre par IP dans notre petit event déjà dans la déclaration du service :
On remarque qu’on a rajouté un troisième paramètre : %trusted_ips%, ce paramètre, on va le définir dans notre fichier config.yml, et qu’on pourra ajuster dans notre config-dev.yml ou notre config_prod.yml. Il contiendra la liste des ips qui pourront consulter le site même si le mode maintenance est actif.
Par exemple, ici en local, on va autoriser 127.0.0.1 à consulter le site. On va actualiser notre petit Event Listener avec ce nouveau paramètre :
Et voilà, maintenant les personnes voulant accéder au site avec les IP inscrites dans vos fichiers de config pourront accéder librement au site ! Alors oui j’ai un peu menti, si vous voulez ajouter des IP autorisées il faudra éditer vos fichier de config. Mais ça arrivera beaucoup moins souvent que de devoir activer/désactiver le mode maintenance.
La cerise sur le gâteau : Afficher que le mode maintenance est actif.
Histoire de ne pas oublier que vous avez activé/désactivé le mode maintenance, je vous propose de pouvoir vérifier dans vos fichiers twig si le mode maintenance est activé. Pour ça, on va déclarer notre paramètre lockPathFile comme variable globale de twig :
Avec cette petite déclaration, vous pouvez accéder à {{ lockFilePath }} dans n’importe quel fichier twig. Plutôt cool, hein ? Sauf que lockFilePath contient le chemin vers le fichier .lock, et non une indication sur l’existence de ce fichier. Pas de soucis, on va faire comme notre eventListener et utiliser la fonction php file_exists(). Sauf que non, on ne peut pas l’appeler telle quelle en twig. On va donc devoir créer une fonction twig qui le fait pour nous :
Et voilà, on a recréé la fonction file_exists() pour twig. Et maintenant on prend notre base.html.twig et…
…On aura un beau bandeau de footer nous affichant que le mode maintenance est activé.
