La version 0.10.0 de Waarp Gateway marque une nouvelle étape dans l'évolution de l'outil avec l'introduction de nouvelles fonctionnalités, des optimisations notables, et des correctifs importants. Comme toujours, cette mise à jour est fortement recommandée pour bénéficier des dernières améliorations en termes de sécurité et de performance.
Notes de version de la mise à jour Waarp Gateway
Principaux changements
Introduction du service SNMP
Waarp Gateway 0.10.0 introduit les premières fonctionnalités liées à la gestion via SNMP. Actuellement, seul l'envoi de notifications SNMP à un agent externe en cas d’erreur de transfert ou de démarrage est pris en charge. Le support des versions SNMPv2 et SNMPv3 est disponible. Un serveur SNMP pour récupérer des informations de diagnostic sera ajouté dans les prochaines versions.
Filtrage d’adresses IP
Cette version introduit un système de filtrage d’adresses IP pour restreindre l’accès des partenaires à Gateway. Ce filtre, disponible via l’API REST et la CLI, permet de spécifier quelles adresses IP sont autorisées à s’authentifier sur Gateway.
Filtrage par ID de flux
Les utilisateurs peuvent maintenant filtrer les transferts en fonction d’un ID de flux spécifique (followID). Cette fonctionnalité est accessible à travers l’API REST et le client terminal, facilitant ainsi la gestion des transferts dans des environnements complexes.
Méthodes d'authentification et optimisations
Comme dans les versions précédentes, cette mise à jour améliore l’authentification et introduit de nouveaux contrôles de sécurité. La gestion des clés et des certificats est uniformisée avec une prise en charge améliorée des mécanismes existants, ainsi qu’une infrastructure robuste pour de futures extensions.
Liste des changements
Nouvelles fonctionnalités
[Feature] #54: Première étape de l’ajout d’un service SNMP. La MIB décrivant ce service SNMP est disponible ici. Pour l’heure, celui-ci ne permet que l’envoi de notifications SNMP à un agent tiers en cas d’erreur de transfert ou en cas d’erreur au démarrage. Un serveur SNMP permettant de récupérer des informations de diagnostic sera implémenté dans une version ultérieure. Waarp-Gateway supporte SNMPv2 et SNMPv3.
[Feature] #401: Ajout d’un filtrage d’IP basique permettant de restreindre les adresses IP autorisées pour un partenaire cherchant à s’authentifier auprès de Gateway. Voir les documentation CLI et REST de gestion des comptes locaux pour plus d’information.
[Feature] #405: Ajout de la possibilité de filtrer les transferts par ID de flux (followID) lors du listing de transferts. Ce changement affecte à la fois l’API REST et le client terminal, se référer à leur docs respectives pour plus de détails.
Correctifs
#406 : Génération automatique d’un followID pour chaque transfert si aucun ID n’est spécifié lors de la création. Ce followID est visible dans les informations de transfert.
#407 : Ajout d’index pour améliorer les performances des requêtes REST et des commandes de listing de transferts, notamment lors du filtrage par date.
Correctifs de la version 0.9.1 (01/07/2024)
Waarp Gateway 0.9.1 a apporté des correctifs critiques suite à la sortie de la version 0.9.0, avec une attention particulière sur la compatibilité rétroactive et les bugs liés à la gestion des mots de passe et des certificats.
:fix:`402` L’ancienne propriété « isTLS » des agents R66 (dépréciée en version 0.7.0 avec la séparation des protocoles R66 et R66-TLS) est de nouveau correctement prise en compte. La rétro-compatibilité avec cette propriété avait été involontairement rompue avec la mise à jour 0.9.0. Cette rétro-compatibilité concerne l’API REST et le fichier d’import/export.
:fix:`-` Le cache d’authentification pour mots de passe introduit en version 0.9.0 fonctionne désormais correctement.
:fix:`-` Les mots de passe des comptes locaux et des partenaires distants peuvent désormais correctement être importés. Un bug introduit en version 0.9.0 empêchait leur création via le champ password (pour les comptes locaux) ou serverPassword (pour les partenaires R66).
:fix:`403` Le certificat R66 legacy est désormais correctement reconnu en tant que tel à sa création, que ce soit via l’import ou via l’API REST. Ce certificat n’était pas correctement reconnu depuis la version 0.9.0 quand celui-ci était ajouté via l’ancien champ certificates, et sa création échouait donc en raison de l’invalidité du certificat.
Comments