Bonjour,
Nous venons de mettre en production la version 3.5 de l’API. Celle-ci apporte son lot de nouvelles fonctionnalités. Nous avons en parallèle passé en production le corpus de l’éditeur Emerald (159954 documents).
Un changelog non exhaustif des modifications apportées à l’API :
- Ajout de l’alias inversé de &noredirect à la route OpenURL : directlink (et ajout de la documentation associée)
- Expiration des adresses IP en cache après 24h (votre accès est accéléré toutes les 24h, passant de ~40ms à ~1ms)
- Création d’une route /mapping qui fournit le mapping elasticsearch actuel en JSON
- Le PMID fonctionne désormais correctement dans les index
- La route /auth vous retourne désormais votre moyen d’authentification et les informations associées (si vous êtes authentifié, sinon vous aurez une erreur HTTP 401 comme d’habitude)
- Refactoring COMPLET du filtrage IP et LDAP, désormais beaucoup plus performant, se basant sur REDIS
Besoin d'aide ?
Consultez notre Faq, la documentation Istex ou nos tutoriels
N’hésitez pas à nous contacter si besoin, nous reviendrons rapidement vers vous !
Écrivez-nous
Erreur : Formulaire de contact non trouvé !
Bonjour,
Merci encore une fois pour tt ce (très) bon boulot !
Est-ce qu’il est possible d’en savoir plus sur l’expiration des IP en cache ? C’est pas très clair…
Emmanuel
Bonjour Emmanuel,
Puisque tu nous demandes d’entrer dans les détails, je vais me faire un plaisir de t’expliquer.
Si tu ne veux pas les détails, fonce au dernier paragraphe 😉
NB: Quand je parle d’IP, il s’agît d’IPv4.
L’API est codée en node.js, nous avions coder la première version du filtrage IP alors qu’elle était encore single-threadée. Lorsque nous avons commencé à utiliser l’API « Cluster » de node.js (un module built-in), et forker l’API afin de la rendre plus stable et plus performante, chacun des fork possédait son propre filtrage, ce qui était très coûteux en terme de mémoire vive car nous mettions tous les ranges d’IP à plat (le range 192.168.0.0 à 192.168.255.255 était éclaté en 65536 IP). Compte tenu de la quantité d’IP et du fait que leur nombre était multiplié par le nombre de forks (1 fork pour 1 CPU de la machine de production, soit 32*65536 IP), nous ne pouvions pas attacher d’information à ces IP au risque de faire swapper la machine.
Il nous fallait donc un point de convergence, REDIS semblait tout désigné. Nous stockons donc dans REDIS, les ranges, sous forme de CIDR. Nous avons donc converti nos ranges, et ceux que l’ABES nous fournit régulièrement, pour les autorisations d’accès aux licences nationales, en IP+Prefix CIDR. Certains ranges ne sont pas conventionnels car certains labos ne veulent pas autoriser l’ensemble des plages IP qui leur appartiennent à accéder à ISTEX (Les WIFI publics par exemple). Néanmoins, malgré cet inconvénient, nous avons moins de 4000 CIDR stockés dans REDIS contre les millions d’IP à plat que nous avions dans des tableaux avant.
Les CIDR servent de clés à REDIS, auxquelles nous attachons des hash (un objet JSON aplati) contenant les informations de chaque CIDR (à qui il appartient, l’IP minimum du range et l’IP maximum). 4000 clés c’est du menu-fretin pour REDIS qui clame haut et fort être capable de parcourir 1 millions de clés en moins de 40 millisecondes sur un PC portable bas-de-gamme. Ce n’est pas étonnant puisque REDIS est une base NO-SQL montée en RAM.
Tu peux penser que je suis hors-sujet mais je pense que c’est utile pour comprendre la réponse à ta question que voilà :
REDIS à beau être rapide, parcourir 4000 CIDR et vérifier que l’adresse IP d’un utilisateur appartient à ceux qui répondent aux critères, est plus coûteux que d’accéder directement à une clé dont on connaît le nom. Pour trouver à quel CIDR appartient l’IPv4 d’un utilisateur, nous considérons que les ranges ne vont pas au-delà de la Classe B (Prefix CIDR /16, soit 16 bits minimum en commun avec l’IP de l’utilisateur), une fois avoir trouvé le CIDR correspondant, nous savons que l’utilisateur est autorisé sur l’API (si nous ne trouvons pas, il ne l’est pas). Une fois que l’utilisateur est validé, son IP est mise en cache afin de ne plus avoir à rescanner la base REDIS à la rechercher du CIDR correspondant. Ce cache expire au bout de 24h après lequel il faudra recalculer le CIDR correspondant. Pour l’utilisateur ça se traduit par une vérification d’authentification de <1ms si son IP est en cache et de ~40ms si il n'y est pas (ou plus). Mais l'authentification n'est qu'une partie du trajet que fait votre requête une fois arrivée sur l'API.
Pour la faire bref, avant nous devions chercher si votre IP était présente dans un tableau de plusieurs millions d'entrées. Maintenant nous calculons à quel CIDR elle appartient puis nous la mettons en cache si elle est autorisée, pour la trouver plus vite ultérieurement (dans les 24h suivantes). Ça se traduit par un énorme gain de perf, un redémarrage plus rapide de l'API et le fait que nous sommes désormais capables de vous dire par quel biais vous êtes authentifié : https://api.istex.fr/auth
En espérant avoir répondu à ta question,
Bien cordialement,
William
Génial !
Merci pour la réponse complète ! C’est plus clair 🙂
Ah et j’en profite : l’ipv6 c’est au programme ? 😉
Désolé je n’avais pas vu cette question 🙂
Non ce n’est pas prévu pour l’instant, les autorisations IP étant essentiellement destinées aux instituts qui sont, pour la grande majorité, déjà en possession de leur plage IPv4 depuis longtemps.
Mais ce n’est pas exclu si le besoin s’en fait ressentir. Et si tu en as le quelconque besoin, fait le nous savoir 🙂