Vermutech #35
Aquesta setmana, entre moltes altres coses, he aplicat una solució clàssica en el món de la informàtica: els semàfors, però fent servir una funcionalitat de PostgreSQL anomenada Advisory Locks. És una eina molt útil perquè permet gestionar seccions crítiques del codi evitant la concurrència, però sense haver de bloquejar files o taules de la base de dades.
Et deixo una pseudoimplementació, ja que la que hem fet està molt lligada al nostre ORM.
Començo amb algunes recomanacions,
💾 Programari
httptab: Permet inspeccionar tots els paquets HTTP(s) d’una aplicació. És molt útil per debugar o investigar com funcionen certs programes.
🤔 Curiositats
Teemoji: Si coneixes la comanda tee de Linux, aquesta eina funciona de manera similar, però analitza el contingut i afegeix emojis segons el que detecta.
📦 Recursos
Un molt bon article sobre com funciona NAT. Recordo que aquest tema em va portar molts maldecaps amb Linux, sobretot quan feia servir un ordinador vell com a router per a tota la meva xarxa local.
🌟 El concepte
Quan una aplicació ha de comunicar-se amb una API, necessita un mecanisme per identificar-se i demostrar que té permís per accedir a les dades o funcionalitats. Una de les formes més comunes de fer-ho és mitjançant una API Key, una cadena de caràcters que actua com una mena de credencial d’accés.
🔍 Com funcionen les API Keys?
Una API Key és un identificador únic que una aplicació o servei ha d’enviar amb cada petició a una API per validar-ne l’autenticació. Quan es registra una aplicació en un servei que ofereix una API, es genera una API Key específica que s’ha d’utilitzar en cada sol·licitud.
Les API Keys es poden incloure en les peticions de diverses maneres:
🔹 Com a paràmetre en l’URL: https://api.exemple.com/data?api_key=123456
🔹 A l’encapçalament de la petició HTTP: Authorization: Bearer 123456
🔹 Com a variable dins del cos de la petició
Tot i que cada mètode té avantatges i inconvenients, en general es recomana no passar mai API Keys en l’URL, ja que poden quedar registrades en els logs del servidor i exposar-se involuntàriament.
⚠️ Perills i males pràctiques
L’ús d’API Keys és senzill i pràctic, però també té limitacions i riscos importants:
🔴 Es poden filtrar fàcilment: Si una API Key es guarda dins del codi font i aquest s’envia a un repositori públic (com GitHub), pot ser detectada per algorismes de cerca i utilitzada per actors malintencionats.
🔴 No controlen qui les fa servir: Qualsevol persona que aconsegueixi una API Key pot utilitzar-la sense cap altre filtre.
🔴 No permeten autenticació real: Només identifiquen l’aplicació, però no confirmen qui és l’usuari que fa la petició.
Per això, és important seguir bones pràctiques per protegir-les:
✅ No incloure API Keys directament en el codi font. Millor utilitzar variables d’entorn o un gestor de secrets.
✅ Restringir les API Keys perquè només funcionin des d’IPs o dominis concrets.
✅ Utilitzar API Keys temporals i renovar-les periòdicament.
✅ Configurar permisos específics per limitar les accions que poden fer.
🔄 Alternatives més segures
Les API Keys són útils per a molts casos, però en entorns més crítics es recomanen mecanismes més avançats com OAuth 2.0, que permet autenticar usuaris i concedir permisos específics a cada aplicació o servei que es connecta a una API.
💖 Feedback
Si t’ha agradat i em vols ajudar, fes arribar aquest contingut a qui creguis que li pot interessar, i entra al canal de Telegram per comentar la publicació.