Chères utilisatrices et utilisateurs,
Je profite de ce premier billet de l’année pour vous présenter, au nom des 3 équipes ISTEX, nos meilleurs vœux pour l’année 2017. Pour notre part, cette année qui débute sera particulière, car elle marquera la fin du projet ISTEX à la fin de l’été, au moins dans sa configuration actuelle.
Concernant l’équipe ISTEX-API, l’enjeu de ces derniers mois de travail sera de finaliser et stabiliser un maximum de fonctionnalités, et surtout de simplifier au maximum la diffusion des ressources acquises. La prochaine version de l’API sera, tout comme les suivantes, un nouveau pas dans cette direction. Ce billet est l’occasion de vous présenter certains changements apportés par cette version, qui devrait être mise en ligne en début de semaine prochaine (qui débute le 23 janvier).
Au niveau de l’authentification
La plus grande nouveauté est la fonctionnalité d’authentification par le mécanisme de fédération d’identités de Renater. Ce système permet à tout membre de l’Enseignement Supérieur et de la Recherche française d’utiliser son fournisseur d’identités habituel (ex: Janus pour le CNRS).
Jusqu’à présent, la fédération d’identités était prise en charge, mais uniquement pour se créer un jeton JWT, qui n’est vraiment utilisable que de manière programmatique. À partir de la semaine prochaine, il sera possible d’accéder aux ressources en plein-texte de manière directe, ceci grâce au paramètre d’URL « auth » de l’API.
Concrètement, ce paramètre « auth » permet de définir la liste des systèmes d’authentification utilisés pour le contrôle d’accès de l’utilisateur. La valeur par défaut est « ip,fede », ce qui signifie que l’adresse IP de l’utilisateur sera contrôlée en premier. Si ce contrôle échoue, le mécanisme de fédération d’identités sera automatiquement enclenché. Deux autres valeurs sont également supportées pour ce paramètre : « jwt » et « ldap ».
Lorsque ce mécanisme sera disponible, vous pourrez le tester très simplement en accédant à n’importe quel fichier PDF, celui-ci par exemple.
Pour plus d’informations sur ce mode d’authentification, consulter la documentation de l’API.
Au niveau du format de la réponse de l’API
Je vous rappelle que, comme indiqué lors d’un précédent billet de blog, la partie « enrichments » de la réponse fait l’objet d’une modification importante.
Au niveau des champs indexés
Les champs « page.first », « page.last », « issue » et « volume » seront dorénavant doublement typés, pour permettre un plus grand nombre d’usages possible.
Les versions directes des champs seront dorénavant de type « integer » : elles seront donc prises en compte comme des nombres entiers, notamment pour les fonctionnalités de tri. Inconvénient majeur : toutes les valeurs ne pouvant pas être converties en nombre (car contenant une lettre par exemple) seront complètement ignorées.
Les versions suffixées par « .raw » seront prises en compte compte comme des chaînes de caractères brutes. Aucune valeur ne sera ignorée, mais le tri devient alphanumérique.
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é !