⚡ ASTUCE RÉSEAU — DNS, enfin compris en 3 minutes Tu tapes github.com dans ton navigateur. Il t'affiche une page. Mais entre les deux, il se passe un truc que 90% des devs ne comprennent pas vraiment. DNS = Domain Name System. C'est l'annuaire d'Internet. Il traduit un nom lisible par un humain (github.com) en une adresse IP compréhensible par une machine (140.82.121.4). Sans DNS, il faudrait mémoriser des milliards d'adresses IP. Avec DNS, tu mémorises des noms. Le DNS fait le reste. Le parcours complet d'une requête DNS — étape par étape : 1️⃣ Ton navigateur : il a peut-être l'IP en cache (de ta dernière visite). Si oui, 0 ms. 2️⃣ Cache OS : sinon, l'OS a peut-être l'IP (via /etc/resolv.conf, qui pointe vers ton serveur DNS — FAI, ou 8.8.8.8, ou 1.1.1.1). 3️⃣ Résolveur récursif : le serveur DNS reçoit la requête. Il regarde son cache. Sinon, il descend la chaîne. 4️⃣ Serveur racine (.) : "Je connais pas github.com, mais je connais qui s'occupe du .com." 5️⃣ Serveur TLD (.com) : "Je connais pas github.com, mais je connais son serveur autoritatif." 6️⃣ Serveur autoritatif : "L'IP de github.com, c'est 140.82.121.4." 7️⃣ Le navigateur : reçoit l'IP, ouvre une connexion TCP, fait un GET / sur HTTPS, charge la page. Tout ça, c'est entre 20 et 200 ms. Maintenant les 5 concepts à garder en tête : 1️⃣ TTL (Time To Live) Quand un serveur autoritatif renvoie l'IP, il indique combien de temps le résolveur doit la stocker (300s, 1h, 24h). Si tu changes l'IP de ton site et que ton TTL est à 86400 (24h), les utilisateurs continueront à voir l'ancienne IP pendant 24h. Avant une migration, baisse le TTL à 300 secondes. github.com. 300 IN A 140.82.121.4 ↑ TTL en secondes 2️⃣ Types d'enregistrements A github.com → 140.82.121.4 (IPv4) AAAA github.com → 2606:4700::6812:... (IPv6) CNAME www.github.com → github.com (alias) MX github.com → mail.github.com (mail) TXT github.com → "v=spf1 include:..." (vérif SPF) NS github.com → ns-1283.awsdns-32.org (autoritatif) 3️⃣ CNAME vs A record Tu veux pointer blog.example.com vers un site sur GitHub Pages : blog.example.com. CNAME aliou.github.io. Le résolveur suit la chaîne : blog.example.com → aliou.github.io → A record → IP. Un CNAME ne peut pas coexister avec d'autres records au même niveau. Si tu mets un CNAME sur example.com, tu ne peux pas mettre de MX ou NS dessus. Limitation du protocole. 4️⃣ DNS over HTTPS (DoH) Le DNS classique est en clair. Ton FAI voit toutes tes requêtes. 1.1.1.1 avec DoH (https://1.1.1.1/dns-query) chiffre ça. Firefox et Chrome supportent DoH nativement. 5️⃣ Split-horizon DNS Ta boîte a api.example.com. Côté interne (VPN) : 10.0.0.5. Côté public : 52.84.150.50. Même nom, IP différente selon d'où vient la requête. C'est ce que font toutes les entreprises. Commande utile : dig est ton meilleur ami pour débugger. $ dig github.com ;; ANSWER SECTION: github.com. 300 IN A 140.82.121.4 ;; Query time: 23 msec ;; SERVER: 1.1.1.1#53 Tu vois le TTL, le record type, l'IP, le temps de réponse, le serveur utilisé. Si ton site ne marche pas après un changement DNS, dig te dit tout. 💾 Enregistre ce post pour ne pas l'oublir. #DevTips #DNS #Networking #WebDev #MetaCodeLearn

🚀 LE SAVIEZ-VOUS — Knight Capital (2012), $440M partis en fumée en 45 minutes 1er août 2012. Knight Capital Group, l'un des plus gros traders algorithmiques de Wall Street, déploie une nouvelle version de son logiciel de trading haute fréquence. C'est un mardi matin, 9h30 heure de New York. Le marché ouvre. En 45 minutes, le logiciel va passer 4 millions d'ordres erronés sur le NYSE. Il va acheter massivement des actions au-dessus du prix du marché, et ne jamais les vendre. 440 millions de dollars de pertes. Une perte supérieure au bénéfice annuel de l'entreprise. Knight Capital meurt presque ce jour-là. Elle sera rachetée en urgence quelques mois plus tard par un concurrent (Virtu Financial + Citadel) à un prix dérisoire. Société fondée en 1995, liquidée en 2012. 17 ans d'histoire, 1 600 employés, rayés de la carte en 45 minutes. Que s'est-il passé ? Knight Capital faisait tourner plusieurs versions de son moteur de trading en parallèle, sur des serveurs différents. Chaque version était identifiée par un "Power Peg" flag — un identifiant dans le code. La nouvelle version, déployée sur 7 des 8 serveurs, était numérotée SMARS-2012-01. Le 8e serveur, oublié, tournait encore sur une vieille version avec un code appelé Power Peg. Le problème : le code Power Peg était un ancien test de stress jamais supprimé du code de production. Quand le marché a ouvert et que la nouvelle version a commencé à envoyer des ordres en masse, un sous-système de l'ancienne version, sur ce 8e serveur, a réagi aux ordres en cascade. Le test de stress est devenu un trader réel. Le code de Power Peg disait essentiellement : "achète à l'offre, vend à la demande, et reverse immédiatement la position". Sauf qu'il ne savait pas qu'il était branché sur le vrai marché. Il a pris l'API pour un simulateur. Pendant 45 minutes, il a exécuté son algorithme de test sur le NYSE avec de l'argent réel. Les leçons — 4, pas une : 1️⃣ Supprime le code mort en production Power Peg était un code de test de stress, écrit en 2003. Il était commenté comme tel, mais il a été activé par accident. Le code mort est un risque dormant. À chaque release, vire ce qui ne sert plus. 2️⃣ Le déploiement doit être progressif et réversible Knight a déployé la nouvelle version sur 7 serveurs en une seule fois. Pas de canary release, pas de feature flag, pas de kill switch rapide. Quand ça a commencé à mal tourner, ils n'avaient aucun moyen d'arrêter le 8e serveur sans relancer tout le cluster. 3️⃣ Les "tests" doivent tester le bon chemin Power Peg avait été testé pendant des années. Mais il était testé en mode "simulateur" — avec un faux marché. Il n'avait jamais été testé en mode "production réelle". Le test passait parce qu'il utilisait des mocks qui ne correspondaient plus à la réalité du code de production. Règle simple : un test qui passe avec un mock ne teste que ton mock. Teste contre l'API réelle, avec un environnement réel, avant chaque release. 4️⃣ Les alarmes doivent être humaines Pendant 45 minutes, le système a généré des alertes sur le dashboard. Mais elles étaient noyées dans le bruit habituel du trading haute fréquence. Personne n'a réalisé pendant 30 minutes que c'était un bug, et non pas un comportement de marché extrême. Une alarme technique sans escalation humaine est inutile. ⚠️ La règle d'or du déploiement : Un déploiement devrait toujours te donner le temps de l'arrêter. Si tu ne peux pas annuler en moins de 5 minutes, c'est trop risqué. Un canary release, un kill switch, un rollback automatique, un monitoring avec une vraie escalade humaine — c'est la base. Pas du luxe. Aujourd'hui, 12 ans après Knight Capital, la plupart des boîtes font toujours des déploiements qui ressemblent à celui-là : "on push sur tous les serveurs d'un coup, on verra si ça marche". Ne sois pas Knight Capital. 💾 Enregistre ce post pour ne pas l'oublir. #DevStory #KnightCapital #Deployment #FeatureFlags #DevTips #MetaCodeLearn

⚡ ASTUCE WEB — JWT décodé en 5 minutes (ce que c'est vraiment, et ce que c'est PAS) Tu vois eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiYWxpb3UiLCJyb2xlIjoiZGV2In0.kQ3... dans ton LocalStorage et tu fais "ouais c'est un token". Mais qu'est-ce qu'il y a DEDANS ? Et surtout : qu'est-ce que tu risques à mal l'utiliser ? JWT = JSON Web Token. C'est un standard (RFC 7519) pour transmettre une information entre deux parties. En général, c'est utilisé pour l'authentification. Structure — 3 parties séparées par des points : HEADER.PAYLOAD.SIGNATURE Chaque partie est en Base64. Tu peux DÉCODER le header et le payload (mais PAS la signature, sinon ça sert à rien) sur jwt.io. Allez, décode celui que t'as dans ton localStorage maintenant. Oui, ce que tu viens de faire est un peu flippant. 1️⃣ HEADER — algorithme + type { "alg": "HS256", "typ": "JWT" } 2️⃣ PAYLOAD — les claims (l'info) { "sub": "aliou", "role": "dev", "iat": 1728000000, // issued at "exp": 1728086400 // expiration (24h) } ⚠️ Tout ce qui est dans le payload est LISIBLE par tout le monde. C'est juste encodé, pas chiffré. Ne mets JAMAIS de mot de passe, d'email, ou de donnée sensible dedans. 3️⃣ SIGNATURE — la preuve d'intégrité Pour HS256, c'est : HMAC_SHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret_server_only ) Le serveur signe avec un secret qu'il garde. Le client reçoit le token. Plus tard, le client renvoie le token, le serveur re-calcule la signature et compare. Si ça matche → le payload n'a pas été modifié. Maintenant, les 4 pièges classiques : ❌ Piège 1 : mettre le JWT dans localStorage Un JWT dans localStorage est accessible à n'importe quel script JS qui passe sur ta page. Si un XSS (Cross-Site Scripting) t'arrive, l'attaquant lit le token, l'envoie à son serveur, et il est connecté à ton compte. Préféré : cookie httpOnly + secure + SameSite=Strict. Le JS ne peut pas le lire, mais le navigateur l'envoie quand même. ❌ Piège 2 : algorithme "none" Par défaut, certaines bibliothèques acceptent l'algorithme "none" — c'est-à-dire pas de signature. Un attaquant peut forger un token admin avec alg: "none", et le serveur l'accepte. Toujours verrouiller l'algorithme côté serveur. // VULNÉRABLE jwt.verify(token, secret); // SAFE — algorithm explicite jwt.verify(token, secret, { algorithms: ['HS256'] }); ❌ Piège 3 : JWT qui n'expire jamais Si tu mets exp très loin dans le futur (ou absent), un token volé est valide pour des mois. Bonne pratique : 15 min à 1h pour un access token. Pour les sessions longues, utilise un refresh token séparé, stocké en cookie httpOnly et rotaté. ❌ Piège 4 : ne pas révoquer un JWT Un JWT est stateless par design. Le serveur ne tient pas de liste des tokens valides. Si un utilisateur change de mot de passe ou est banni, son ancien JWT reste valide jusqu'à expiration. Solutions : - Stocker un jti (JWT ID) unique par token, blacklisté en cas de révocation. - Refresh tokens courts + DB check à chaque refresh. - Au minimum, vérifier en DB à chaque requête critique (ce qui rend le JWT "stateful", mais c'est OK pour un site de e-commerce). ✅ Le bon flow : // 1. Login POST /login { email, password } → 200 { accessToken: "eyJ..." } // 15 min → Set-Cookie: refreshToken=...; HttpOnly; Secure // 2. Requête authentifiée GET /api/me Authorization: Bearer eyJ... // 3. Quand l'access token expire POST /refresh (cookie auto-envoyé) → 200 { accessToken: "eyJ...nouveau" } ⚠️ Dernier rappel : JWT n'est PAS un serveur de sessions. C'est un format de token. Tu peux l'utiliser pour des sessions, mais tu peux aussi l'utiliser pour des API entre services, des magic links email, des confirmations de paiement, etc. Chaque cas d'usage a ses propres règles. 💾 Enregistre ce post pour ne pas l'oublir. #WebDev #JWT #Authentication #Security #DevTips #MetaCodeLearn