Surveillez l'utilisation de votre clé avant d'atteindre une limite
Surveiller vos en-têtes de quota au fil de l'eau vous indique quand une limite approche, bien avant qu'une requête ne soit effectivement refusée.
Distinguer les visiteurs IPv4 et IPv6 dans vos journaux
Une adresse comme 203.0.113.42 et une autre comme 2001:db8::1 sont visiblement différentes, mais une fois les adresses noyées dans un fichier journal ou une colonne de base de données, un script qui suppose un seul format traitera l'autre de travers sans rien signaler.
Lire le champ version
L'endpoint /v1/ip renvoie un champ version dans chaque réponse, soit 4, soit 6, avec le reste des données de localisation. Inutile d'analyser vous-même la chaîne d'adresse pour savoir à quelle famille elle appartient.
GET /v1/ip?ip=2001:db8::1{
"status": "ok",
"ip": "2001:db8::1",
"version": 6,
"found": true,
"country": "Canada",
"country_code": "CA",
"region": "Ontario",
"city": "Toronto",
"postcode": "M5H",
"lat": 43.6511,
"lon": -79.3808,
"timezone": "America/Toronto",
"asn": 4321,
"org": "Example ISP"
}Pourquoi cette distinction compte pour le quota
Le quota gratuit est compté par réseau, et ce réseau est défini différemment pour chaque famille d'adresses : toutes les adresses IPv4 d'un même /24 partagent un quota, et toutes les adresses IPv6 d'un même /48 partagent un quota. Un seul client IPv6 disposant d'un grand bloc attribué peut apparaître dans vos journaux comme de nombreuses adresses différentes tout en se trouvant en réalité dans un seul quota partagé, et connaître la version vous aide à regrouper les entrées du journal selon la bonne limite de réseau, au lieu de traiter chaque chaîne d'adresse distincte comme sans rapport avec les autres.
Un cas concret où cela pose problème
Un visiteur dont la connexion internet domestique prend en charge les deux familles d'adresses peut apparaître dans vos journaux sous deux adresses apparemment sans rapport au fil de deux visites, l'une IPv4 et l'autre IPv6, selon celle que son appareil a utilisée ce jour-là. Traité naïvement, cela ressemble à deux visiteurs différents. Regrouper par version en plus d'un identifiant stable comme un cookie de session, plutôt que par adresse brute seule, évite de gonfler le nombre de visiteurs ou de répartir l'historique d'un même client sur deux profils.
Gestion pratique des journaux
Lorsque vous écrivez votre propre analytique ou votre propre détection des abus à partir de journaux bruts, faites une branche selon le champ version avant d'essayer de calculer un préfixe réseau, car un masque /24 n'a aucun sens appliqué à une adresse IPv6 et un masque /48 n'a aucun sens appliqué à une adresse IPv4. Stockez la version à côté de l'adresse elle-même plutôt que de la redéduire par analyse de chaîne chaque fois que vous relisez le journal.
Une erreur à éviter
Appliquer une seule expression régulière écrite pour la notation pointée IPv4 à une colonne qui contient aussi des adresses IPv6 est une source discrète de lignes de journal perdues ou mal classées. Testez explicitement tout code d'analyse d'adresses sur les deux formats, y compris la notation abrégée à double deux-points couramment utilisée par les adresses IPv6, plutôt que de supposer qu'un seul motif couvre les deux familles.
Le coût de la vérification
Obtenir la version de cette façon coûte une requête par adresse vérifiée, comme toute autre recherche d'IP. Si vous auditez un gros fichier journal, regroupez les adresses dans un POST en masse plutôt qu'une requête par ligne : le coût par élément reste le même, avec beaucoup moins d'appels.
Traiter IPv4 et IPv6 comme deux familles d'adresses réellement distinctes, et pas seulement comme des chaînes de longueurs différentes, évite une catégorie de bugs qui n'apparaît qu'une fois que le trafic IPv6 représente une part significative de vos visiteurs. La documentation de la recherche IPv6 couvre l'endpoint en détail.