afelton demandée il y a 2 ans
Bonjour,
Nous avons utilisé l’outil OCTAVE pour préparer un versement et avons nettoyé ultérieurement le bordereau en utilisant les outils dédiés de la SEDAbox (intégration de l’identifiant du service versant et du service d’archives ainsi que nettoyage des éléments de traces). Lors du versement par upload de bordereau dans as@lae, le transfert est rejeté, un message de non conformité (error code 101) relatif à la présence de l’attribut « algorithme » (pour l’élément MessageDigest) est affiché lors de l’analyse du transfert. En effet, l’attribut en question est identifié comme non conforme dans la mesure où il est orthographié avec un « e ». Pourtant, après vérification du bordereau, l’attribut « algorithm » est bien orthographié et il n’y a aucune trace de cet attribut « algorithme ».
Ce problème est apparu à deux reprises sur des transferts en SEDA 2.1 mais nous ne l’avons pas constaté pour un transfert en SEDA 1.0.
Cette problématique peut-elle être liée à l’utilisation d’OCTAVE ou à celle des outils de compatibilité de la SEDAbox avec as@lae ?
Merci,
admin admin personnel répondue il y a 2 ans
Le problème rencontré provient du résultat de la vérification d’intégrité réalisée par le SAE. En SEDA 2.1, <MessageDigest> est obligatoire et doit être utilisé avec l’attribut algorithm. As@lae semble ne pas consulter la valeur de cet attribut (qui est en SHA-512 par défaut dans Octave) et n’est compatible par défaut qu’avec SHA-256.
La véritable erreur ne porte donc pas sur l’attribut algorithm renseigné par Octave mais sur la valeur du hash calculé par défaut en SHA-512 quand le SAE attend du SHA-256. L’erreur remontée pourrait être que l’algorithme de hachage n’est pas le bon.
La SEDABox ne recalcule pas les hash d’Octave car on ne lui transmet pas les binaires associés. Pour corriger le problème, il faut configurer Octave pour qu’il fonctionne en SHA-256. Nous venons de publier une réponse à cette question sur le Comptoir (https://hub.mintika.fr/question/probleme-de-hach-sip/). Dans votre cas, il va falloir relancer tout le traitement, les hash étant calculés dans Octave lors de la capture. De cette manière, cela devrait parfaitement fonctionner en passant par la SEDABox après l’export d’Octave.
Le problème de l’algorithme utilisé par défaut dans Octave ne se pose pas en SEDA 1 car cet attribut n’est pas obligatoire dans cette version du standard. De ce fait, la SEDABox peut passer outre et laisser As@lae réaliser son calcul dans l’algorithme de son choix (SHA-256).