Release 25.R3: April 2025 (Draft)

Comportement modifié

Voici quelques-uns des changements de comportement dont vous voudrez peut-être être conscient.

HTML Code

Pour des raisons de sécurité, nous n’autoriserons plus l’utilisation de code HTML dans les champs de saisie de OneSpan Sign. (réfs PB-114029)

Pour les champs de transaction et de document, cela inclut les éléments suivants :

• Noms des transactions et des modèles

• Descriptions des transactions et des modèles

• Noms des documents

• Signatures, noms de champs et info-bulles

Pour les champs de page d’administration, cela inclut :

• Utilisateurs

• Rôles

• Groupe

• Champs personnalisés

• Préférences en matière de notarisation

• Commissions notariales

En plus de ce qui précède, le code HTML ne sera plus autorisé dans :

• La page d’enregistrement du compte

• La page Fast Track

• Lors de l’utilisation de l’envoi en bloc csv

Amélioration de la génération de clés API

Pour augmenter la sécurité de nos clés API, nous avons mis en place un algorithme de nouvelle génération qui générera des clés plus longues. Ce changement signifie que toutes les clés API existantes ont été converties pour suivre le nouveau format. De plus, toutes les nouvelles clés créées lors de la création d’un nouvel utilisateur suivront également ce nouveau format.

Notez que toutes les intégrations qui ont été implémentées à l’aide des anciennes clés continueront à fonctionner. Ces clés resteront fonctionnelles jusqu’au 1er mars 2026. À ce moment-là, les clés API plus courtes ne fonctionneront plus.

Que dois-je faire ?

Pour vous préparer à ce changement, OneSpan vous recommande de faire ce qui suit :

1. Vérifiez que vos systèmes et applications peuvent prendre en charge le nouveau format de clé API plus long. Cela peut impliquer des modifications de votre base de code et de vos paramètres de configuration.

2. Planifiez votre migration vers le nouveau format de clé API plus long dès que possible. Bien que ces clés soient générées pour vous, toutes les intégrations que vous avez effectuées à l’aide du format de clé plus court devront être mises à jour manuellement.

3. Migrez vos environnements Sandbox vers le nouveau format de clé API. Pour garantir une transition en douceur, nous vous recommandons vivement de tester les nouvelles clés API plus longues dans notre environnement Sandbox avant le déploiement en production.

4. Une fois que vous avez migré avec succès vos environnements Sandbox, migrez vos environnements de production vers le nouveau format de clé API.

Si vous avez besoin d’aide pendant cette phase de transition, veuillez contacter notre Support Team .

Changements supplémentaires de comportement

• Nous avons introduit une validation supplémentaire pour les URL de rappel afin d’améliorer la sécurité et d’éviter les erreurs de configuration. Cela inclut des contrôles plus stricts des adresses IP (IPv4 et IPv6), des noms de domaine et des schémas d’URL. (refs PB-82547)

• Nous ne vous permettons plus d’envoyer une transaction lorsqu’un destinataire dispose à la fois des champs d’acceptation uniquement et de signature sur le même document. Auparavant, l’envoi d’une transaction comme celle-ci entraînait l’apparition d’une erreur lorsque le destinataire tentait de signer ses documents. Les destinataires peuvent toujours se voir attribuer des champs Acceptation uniquement et Signature, à condition que ces types de champs se trouvent sur des documents distincts dans la transaction. (réfs PB-112293)

• Nos modèles d’e-mails de signataire prêts à l’emploi incluent désormais des avertissements supplémentaires qui rappellent aux signataires de ne pas transférer ou signer de demandes de signature inattendues. (réfs PB-115478)

Changements à venir

Voici quelques-unes des nouvelles fonctionnalités, modifications et améliorations que nous présenterons dans une prochaine version.

Dépréciation des chiffrements TLS hérités

Dans le cadre de notre engagement continu en faveur de la sécurité, nous allons déprécier certains chiffrements TLS hérités.

Étant donné que les chiffrements TLS peuvent être définis par nom d’hôte, nous avons modifié le plan d’obsolescence du chiffrement pour donner à tous les clients plus de temps pour tester ces modifications dans leurs environnements Sandbox. En tant que tel, nous éliminerons progressivement les chiffrements suivants aux dates suivantes :

Que dois-je faire ?

Nous vous recommandons de commencer immédiatement à travailler avec votre équipe informatique pour vous assurer que votre cadre d’intégration n’utilise aucune des suites de chiffrement mentionnées ci-dessus. Une fois terminé, veuillez tester votre environnement de bac à sable OneSpan Sign pour vous assurer que toutes les communications TLS fonctionnent correctement. Il s’agit d’une étape importante qui permet à votre organisation de ne pas subir d’interruptions de service.

Pour plus d’informations, reportez-vous à laSupported TLS Versions .

Modifications apportées au modèle email.delegation.activate

Dans une prochaine version, le modèle d’e-mail e-mail e.delegation.activate sera mis à jour pour inclure la date de début de la délégation. (réfs PB-116151)

La chaîne Votre rôle en tant que délégué expirera le : $EXPIRY_DATE ;. sera remplacé par Votre rôle en tant que délégué s’étendra de $DELEGATION_START_DATE ; à $EXPIRY_DATE ;.

Aucune modification ne sera apportée à l’adresse e-mail email.delegation.activate au niveau du compte.

Quoi de neuf

Voici quelques-unes des nouvelles fonctionnalités et améliorations que nous avons apportées à cette version.

Groupe ad hoc Disponibilité générale :

Nous sommes heureux de vous annoncer que nos Ad Hoc Groups sont maintenant en GA !

En plus de toutes les fonctionnalités intéressantes introduites dans notre BETA versions de cette fonctionnalité, cette nouvelle version inclut désormais les améliorations suivantes : (refs PB-113276)

• Vous pouvez maintenant ajouter « Moi-même » en tant que membre d’un groupe ad hoc

• À l’aide de l’interface utilisateur de l’expéditeur, vous pouvez désormais ajouter le même destinataire en tant que signataire individuel et en tant que membre d’un groupe ad hoc.

• Duplicate signers peut être utilisé

• Attachments peuvent être ajoutés

• Le document de consentement aux divulgations et signatures électroniques sera désormais affiché pour tous les membres du Groupe spécial

• Le type de signature Mobile Capture est disponible

• L’extraction Document et Text Tag sont désormais prises en charge

• Enregistrement et application d’un layout avec des groupes ad hoc

• Reporting

Nouvelle présentation introductive !

Notre présentation améliorée du produit pour les nouveaux utilisateurs est maintenant disponible. Grâce à cette procédure pas à pas améliorée, les nouveaux utilisateurs peuvent suivre un guide étape par étape pour créer, préparer et envoyer leur première transaction. (réfs PB-111168)

Limitation du débit

Nous avons mis en place une fonctionnalité de limitation du débit qui limitera le nombre de notifications qu’un seul utilisateur recevrait. Cela permettra d’éviter que les signataires ne soient spammés par des notifications inutiles. La limite de débit actuelle est de 20 notifications sur une période de 2 heures. Si vous avez besoin de le modifier, contactez notre Support Team .

Intégrations de flux de travail

Nous avons apporté d’autres améliorations au cadre de Workday Business Process que nous avons introduit en Release 25.R.2. (réfs DAG-172)

Améliorations de OneSpan Sign pour SharePoint

• Les utilisateurs peuvent désormais ajouter une méthode d’authentification (SMS, Q&R) pour les contacts.

• Vous pouvez maintenant définir un ordre de signature pour vos contacts. Notez que la plage d’ordre de signature est comprise entre 0 et 99 et que nous vous recommandons de définir un ordre de signature par défaut. Si plusieurs contacts ont le même ordre de signature attribué, la signature parallèle est appliquée.

Bogue

Les problèmes suivants ont été résolus dans cette version :

Intégrateurs

• La tentative d’utilisation de l’appel /api/account/usage d’API entraînait parfois une erreur 500 (délai d’expiration). Cette erreur n’apparaît plus. (refs PB-108395)

Expéditeurs

• Lors de la modification et du renvoi d’une transaction, la date d’expiration de la transaction n’était pas toujours exacte. Ce problème a été résolu. (refs PB-114251)

• Dans les environnements australiens, la date d’expiration de certaines transactions n’était pas toujours exacte. Cela s’est produit lors du passage à l’heure d’été et a été causé par une erreur de calcul en heures (qui serait décalée d’une ou deux). Ce problème a été résolu et la date d’expiration correcte s’affiche. (refs PB-114354)

• Lors de la saisie manuelle d’une date d’expiration pour une transaction à l’aide de l’interface utilisateur de l’expéditeur, la transaction expire à 4h00 GMT à la date d’expiration prévue de la transaction, au lieu de la dernière mise à jour de la transaction. Désormais, les transactions expirent à la date d’expiration définie au moment de la dernière mise à jour de la transaction, et non à 4h00 GMT. (réfs PB-116514)

Signataires

• Nous avons résolu un problème qui empêchait la valeur par défaut d’un champ d’apparaître lors de la cérémonie de signature lorsque des conditions étaient liées à ce champ. (refs PB-114666)

Voltige

• Un message de rappel EDEPOSIT_FAILURE était parfois signalé lorsque des champs facultatifs d’une transaction étaient manquants. Comme ces champs étaient facultatifs, cet avertissement n’aurait pas dû apparaître. Cela a été corrigé. (réfs PB-114578)

Vulnérabilités

Nous avons résolu un problème qui pouvait entraîner l’application d’une formule dans le rapport téléchargé pour une transaction dont le nom commence par l’un des caractères répertoriés ci-dessous. Désormais, lorsqu’un nom de transaction commence par l’un des symboles suivants, il est précédé d’un ' dans le rapport téléchargé. (réfs PB-99804)