Le problème des clés d'API qui n'expirent jamais
Une clé émise il y a des années, jamais renouvelée et toujours valide aujourd'hui n'est pas une commodité. C'est un risque que personne n'a vraiment examiné depuis des années.
Ce que le secteur comprend encore mal à propos de l'adoption de l'IPv6
IPv6 est disponible depuis assez longtemps pour que le traiter comme une préoccupation secondaire ne soit plus un raccourci d'ingénierie raisonnable, et pourtant de nombreux outils liés aux IP se comportent encore comme si IPv4 était le vrai trafic et IPv6 l'exception à gérer s'il reste du temps. Cela se manifeste par de petites choses : une logique de limite de débit écrite autour de blocs d'adresses de type IPv4 sans notion équivalente et bien pensée pour IPv6, ou une documentation qui suppose discrètement un format d'adresse IPv4 dans ses exemples et laisse la gestion d'IPv6 comme une réflexion après coup implicite.
Nous avons délibérément construit le suivi des quotas au niveau du réseau autour des deux familles d'adresses, et non comme un correctif IPv6 greffé sur une logique pensée d'abord pour IPv4. Chaque réseau dispose d'un quota gratuit partagé, un bloc /24 pour les adresses IPv4 et un bloc /48 pour les adresses IPv6, et les deux sont traités comme des regroupements de premier ordre, au lieu que l'un soit la conception principale et l'autre un aménagement. La distinction entre un /24 et un /48 n'est pas arbitraire. Elle reflète la façon dont chaque famille d'adresses est réellement attribuée par les registres internet régionaux chargés de distribuer les blocs, de sorte que le regroupement a le même sens pratique, un réseau de taille raisonnable, dans les deux cas.
Se tromper sur ce point compte particulièrement pour une API de données de localisation et d'IP, car toute la catégorie des recherches au niveau du réseau et basées sur l'IP dépend de l'analyse, de la correspondance et de la limitation de débit correctes pour les deux formats d'adresse. Une API qui traite discrètement IPv6 comme un cas limite risque davantage de produire un comportement de quota incohérent, des regroupements de réseau incorrects ou de véritables échecs d'analyse pour le trafic IPv6, au moment même où l'adoption d'IPv6 continue de progresser et où une part significative des requêtes réelles arrive par IPv6 plutôt que par IPv4.
Si le secteur investit si peu dans ce domaine, c'est en partie parce que le trafic IPv4 représente encore une grande part du volume total pour de nombreux services, ce qui donne aux cas limites d'IPv6 l'air d'une faible priorité au regard de l'effort nécessaire pour les traiter vraiment correctement. Nous pensons que ce raisonnement sous-estime trop la tendance. Une part du trafic qui ne cesse de croître est mal servie par une infrastructure qui la traite comme une minorité permanente, et le coût d'une gestion correcte d'IPv6 ne fait qu'augmenter à mesure que la logique centrale d'un système est construite en supposant IPv4 par défaut.
Rien de tout cela n'est une affirmation spectaculaire. C'est une demande de prendre IPv6 aussi au sérieux qu'IPv4 dans la conception réelle de la limitation de débit, du suivi des quotas et de la logique de recherche, et pas seulement dans une case de conformité indiquant qu'une API accepte techniquement les adresses IPv6 sans erreur de syntaxe. Accepter un format d'adresse et le traiter avec le même soin que le format le plus courant sont deux réussites différentes, et une grande partie de l'infrastructure de ce secteur n'a vraiment accompli que la première.