OneSpan Sign Release 11.32: Amélioration de la confidentialité des signataires

Duo Liang, février 20, 2020

OneSpan Sign Release 11.32: Improved Signer Privacy

OneSpan Sign version 11.32 a récemment été déployé dans l’environnement de prévisualisation et de bac à sable. Dans cette nouvelle version, nous avons supprimé l’adresse e-mail du signataire des paramètres de l’URL de transfert pour mieux protéger la vie privée du signataire, mis en œuvre le navigateur signature dans la nouvelle cérémonie de signataire, permis aux expéditeurs avec la possibilité de configurer des logiques conditionnelles à la champs de signature, et a ajouté plusieurs corrections de bogues. Vous pouvez trouver les dates de déploiement de tous nos environnements sur notre page Trust Center.

Dans ce blog, nous allons nous concentrer sur le changement de comportement URL de transfert et expliquer comment cela peut affecter votre application ainsi que comment vous pouvez ajuster votre intégration pour travailler autour. Commençons !

Qu’est-ce que l’URL de transfert ?

Une URL de transfert est un lien de redirection pré-réglé dans les paramètres du package qui permet aux utilisateurs de déterminer où la cérémonie de signature sera déplacée après qu’un destinataire interagit avec une transaction. Si vous n’êtes pas familier avec les bases du concept ou si vous êtes intéressé à tirer parti de cette fonctionnalité, nous vous encourageons à lire notre article de blog "Handover URL" à l’avance. 2-20-1

L’URL de transfert sera déclenchée dans certains scénarios, et elle peut également être utilisée comme un crochet Web pour envoyer des messages en temps réel à vos points de terminaison sur l’événement déclenché. Par exemple, lorsque votre destinataire a refusé ou complété une transaction, vous souhaitez être au courant du changement d’état et mettre à jour votre base de données locale. L’une des solutions consiste à répondre aux paramètres attachés à l’URL de transfert et à utiliser ce bit d’information pour localiser l’événement. Voici une histoire d’utilisateur en pratique réelle:

Si vous avez spécifié l’URL de transfert comme :

"https://localhost/oss/handover"

Après que le destinataire avec l’ID de signataire de "Signer1" a refusé la transaction (ID de "T840KlFsIeC--LqGu9O9Enp9T6I"), les informations associées à cet événement seront passées par paramètres, et le lien réel que le destinataire frappera ressemble à:

"https://localhost/oss/handover?package=T840KlFsIeC--LqGu9O9Enp9T6I%3D-signer-Signer1-status-PACKAGE_DECLINE"

Qu’est-ce qui a été changé?

Il est pratique de tirer parti de l’URL de transfert pour envoyer des informations, mais les URL et les paramètres de requête ne sont pas toujours sécurisés. La transmission d’informations sensibles de cette façon pourrait vous rendre vulnérable aux attaques.

Pour mieux s’aligner sur les meilleures pratiques de l’industrie, depuis 11.32, OneSpan Sign a supprimé toutes les informations personnelles du signataire (email, pour être précis) des paramètres de l’URL de transfert. C’est-à-dire que la cérémonie de signature classique, la cérémonie de signature mobile (MSC) et la nouvelle expérience de signataire (NSC) ne comprennent plus que trois paramètres : « paquet », « signataire » et « statut ».

Comment cela pourrait-il m’affecter?

Si votre intégration utilisée pour répondre au paramètre d’email de l’URL de transfert pour identifier les informations de signataire, vous devrez modifier le projet et utiliser l’ID de signataire à la place pour faire le même travail. Nous expliquerons cette approche dans cette section.

Tout d’abord, il est important de savoir que l’ID du signataire dans l’URL de transfert se réfère à l’ID de signataire plutôt que l’ID de rôle et être conscient que ces deux concepts hébergent des ID différents qui sont faciles à mélanger. Pour en savoir plus sur les différences détaillées entre le signataire et le rôle, allez consulter notre blog précédent "Role vs Signer - Partie 1".

Ensuite, la question se résume à la façon d’utiliser l’ID de signataire pour localiser le destinataire. Si vous avez spécifié l’ID du signataire et stocké les informations dans votre base de données locale, vous pouvez simplement modifier les critères de recherche de l’e-mail du signataire à l’ID et localiser les informations du signataire. Sinon, si vous n’avez pas stocker l’ID de signataire dans la base de données, vous devrez faire un appel API/SDK supplémentaire et introduire des logiques supplémentaires.

Pour les utilisateurs de REST API, vous effectuez d’abord une API de récupération de paquets pour obtenir toutes les métadonnées du paquet :

Demande HTTP

GET /api/packages/ 'packageId'

En-têtes HTTP

Accepter : application/json; esl-api-version 11,21 
Autorisation : Base de base api_key

Ensuite, vous devez passer en boucle les informations du signataire et vérifier l’ID du signataire. L’ID de signataire est hébergé sous le tableau "rôles" - tableau "signataires" - "id".

Pour les utilisateurs sDK, si vous avez spécifié l’ID personnalisé pour votre objet de signature (dans ce cas, l’ID de rôle et l’ID de signataire sont les mêmes), vous pouvez récupérer les informations de signataire via SDK, et ci-dessous le code Java SDK vous donne l’idée :

		forfait string finalId -"4hCMvx-gZdiu502pXcISHLn0pKc";
		string finale signataires -"Signer1";
		DocumentPackage pkg - eslClient.getPackage (nouveau PackageId(packageId));
		pour (Signer signataire : pkg.getSigners())
			if (signerId.equals(signer.getId)))
				System.out.println ("Signer’s Email: " ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' Prénom du signataire: " 'signer.getFirstName') ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' Nom de famille du signataire: " - signataire.getLastName());
			}
		}

Dans le cas où l’ID de rôle et l’ID de signataire ne sont pas identiques, vous vous tourneriez vers l’approche rest API en raison de la nature de SDK qu’il n’expose pas l’ID de signataire.

Grâce au blog d’aujourd’hui, si votre application a été affectée par le changement de produit, vous devriez être en mesure de trouver une solution de contournement pour éviter toute interruption de votre service avant 11h32 déployé dans l’environnement de production.

Si vous avez des questions concernant ce blog ou toute autre chose concernant l'intégration de OneSpan Sign dans votre application, visitez les Forums communautairesdes développeurs . Vos commentaires sont importants pour nous!