1. Notes de distribution 5.4.0
Date de distribution: 26-09-2019
1.1 Nouvelles fonctionnalités d’eSignatures 5.4.0
Niveau de correspondance réduit dans Mandated Signer Validation (validation du signataire mandaté)
Dans les versions précédentes, lorsque nameandbirthdate était utilisé comme type de signataire mandaté (Mandated Signer Type) pour eID, itsme ou iDIN, le niveau de correspondance entre les informations relatives au signataire et les données extraites de la méthode de signature devait être de 100 %. La moindre différence pouvait signifier que le signataire n’était « pas mandaté pour signer » le document.
Depuis eSignatures 5.4, les administrateurs système peuvent configurer un niveau de correspondance (MatchLevel) pour chacun de ces types de signatures dans l’Index de configuration, sous Signing Options Settings. Cela vous permet de configurer le degré de précision avec lequel le prénom et le nom de famille des contacts doivent correspondre aux données fournies par itsme, iDIN ou la carte eID. Veuillez noter que le degré de précision est calculé en appliquant l’algorithme Jaro-Winkler. La précision ne dépend donc pas du nombre exact de caractères concordants.
Les utilisateurs de l’API peuvent également choisir d’ignorer la valeur MatchLevel configurée au niveau de l’environnement en passant le paramètre MatchLevel dans les appels Set Process Information et Instant Package Creation.
Fin du flux de signature
En tant qu’initiateur, vous pouvez à présent mettre fin au flux de signature à votre convenance. Dès qu’un package a été signé par au moins une partie, mais qu’il contient encore des champs non signés qui doivent être signés par d’autres, vous pouvez désormais choisir de mettre fin au flux et de marquer le package comme étant terminé.
Le document devient ainsi disponible en téléchargement et il n’est plus nécessaire d’attendre qu’il soit signé par toutes les parties pour que quiconque puisse le télécharger.
En tant qu’utilisateur de l’API, vous pouvez mettre fin au flux de signature en effectuant un appel Skip Signers (ignorer les signataires). Tous les signataires qui n’ont pas encore signé reçoivent le statut « Skipped » (ignoré) et le package est marqué comme étant terminé.
Identités gérées pour les ressources Azure
eSignatures stocke un grand nombre de fichiers durant le traitement des documents. Pour le stockage des fichiers dans Microsoft Azure Blob Storage, eSignatures prend désormais en charge l’utilisation des identités gérées (managed identities). Grâce à la fonctionnalité d’identités gérées, les administrateurs système peuvent utiliser le système de contrôle Azure Role Based Access Control (RBAC) pour accorder l’accès au compte de stockage. De cette manière, aucun identifiant n’est nécessaire pour accéder au stockage.
L’un des avantages supplémentaires, c’est que vous n’avez plus besoin de séparer des comptes de stockage pour héberger plusieurs clients. Les identités gérées permettent de s’assurer que les clients n’ont accès qu’aux fichiers qu’ils sont censés utiliser.
Les administrateurs système peuvent configurer la fonctionnalité d’identités gérées dans l’Index de configuration, sous File Storage Settings.
Omission du texte accompagnant la signature visuelle
Les méthodes de signature ci-après placent une image de la signature, créée par le signataire, sur le document : méthode manuelle, méthode manuelle + eID et méthode biométrique. Lorsque vous utilisez l’une de ces méthodes de signature, le texte par défaut suivant est placé sur l’image de la signature : « Digitally signed by X on behalf of X » (numériquement signé par X au nom de X), suivi de la date et de l’heure.
Dans eSignatures 5.4, les administrateurs système peuvent choisir d’omettre ce texte afin que seule l’image de la signature soit visible sur le document signé. Sachez toutefois que le texte reste stocké dans la signature numérique ; il est uniquement supprimé de l’image. Veuillez noter également que les mentions légales éventuelles seront elles aussi omises de l’image de la signature.
1.2 Améliorations
Nouvelles tentatives en cas d’erreurs Callback
Lorsqu’une erreur de rappel Callback se produit, eSignatures effectue désormais plusieurs tentatives d’accès au système externe visé par l’URL de rappel Callback.
Par défaut, eSignatures réessaie le rappel trois fois durant trois cycles de tentative. Si l’erreur se produit toujours après le nombre de tentatives fixé, le document ou le package est placé dans la file d’attente « empoisonnée ».
Les administrateurs système peuvent également choisir de personnaliser le mécanisme de nouvelles tentatives dans le fichier de configuration Worker.
Redirection configurable avec la signature asynchrone
En cas d’utilisation d’une méthode de signature asynchrone, les utilisateurs pouvaient déjà clôturer la session de signature et passer à d’autres tâches pendant que la signature se poursuivait en arrière-plan, sauf si une URL RedirectUrl avait été configurée dans l’API. Dans ce cas, le bouton de fermeture Close n’était pas disponible et l’utilisateur devait attendre que tous les documents soient signés avant d’être redirigé.
Dans eSignatures 5.4, les utilisateurs de l’API peuvent désormais configurer le moment de la redirection : 1) immediately, dès que l’utilisateur clique sur Start signing, 2) after a delay, après un délai de 5 secondes ou 3) after session, après la session une fois que tous les documents de la session ont été signés.
Informations supplémentaires dans les preuves d’audit
Les preuves d’audit (Audit Proofs) contiennent désormais également l’adresse IP du signataire.
L’adresse IP du signataire est ajoutée aux preuves chaque fois qu’un événement de signature se produit, comme au début de la signature, à la fin de la signature, à l’envoi d’un SMS OTP, à l’envoi d’un e-mail OTP, etc.
1.3 Problèmes résolues
Jira code | Issue code | Description |
---|---|---|
CEP-6675 | 30863 | Signer could not always view package details in Signer Portal. |
CEP-6661 | 31289 | Branding issue in Edit Contact window has been fixed. |
CEP-6560 | 31093 | WYSIWYS finishing issue has been fixed. |
CEP-6528 | / | Branding issue during upload has been fixed. |
CEP-6456 | / | Wrong error message was displayed when QuickSign is disabled. |
CEP-6345 | / | Connective logo has been removed from console. |
CEP-6287 | / | Search issues in Theme section have been fixed. |
CEP-5393 | / | Azure Webjob shutdown issue during asynchronous signing has been fixed. |
CEP-5286 | / | Signed document download issue has been fixed. |
CEP-5066 | / | Marker issue has been fixed. |
1.4 Problèmes connus
eSignatures 5.4.0
Jira code | Issue code | Description |
---|---|---|
CEP-6651 | / | QuickSigning multiple fields in a single document while the end document flow has been initialized currently causes Deadlock logs. |
CEP-6589 | / | When the status of a document is “Ending” it’s currently not possible to view its details. |
eSignatures 5.3.0
Jira code | Issue code | Description |
---|---|---|
CEP-5944 | / | Itsme scrolling is not as smooth as expected on Safari on iPhone. |
eSignatures 5.2.4
Jira code | Issue code | Description |
---|---|---|
CEP-5564 | / | When a package contains both an asynchronous and synchronous signing method, and the asynchronous signing fails, the signing session cannot be recovered. |
eSignatures 5.2.0
Jira code | Issue code | Description |
---|---|---|
CEP-4817 | / | Display bugs when using complex signing on Safari and Chrome |
eSignatures 5.1.1
Jira code | Issue code | Description |
---|---|---|
CEP-4719 | / | The timeout of the session is currently absolute. Users are logged out even if they have been active. |
Older known issues
Jira code | Issue code | Description |
---|---|---|
/ | / | German installation of Chrome can generate errors during signing. |
1.5 Limitations connues
Général
- Un package ne peut pas excéder 150 Mo.
- Un seul document à l'intérieur d'un package ne peut pas excéder 30 Mo.
- Un package peut contenir un maximum de 15 documents.
- Un fichier .xml ne peut pas contenir plus de 2 millions de caractères par fichier. Un package ne peut pas contenir plus de 15 fichiers .xml.
- Les fichiers volumineux peuvent affecter les performances de signature selon la connexion Internet de l'utilisateur.
- Les documents qui font plus de 3,99 m sur 3,99 m ne sont pas pris en charge.
- Uploading PDF portfolios is not supported.
- Le chargement des documents PDF/A est uniquement autorisé si le format est PDF/A_2A ou PDF/A_1A.
- Lorsque vous chargez des documents PDF contenant déjà des champs de signature (créés dans une solution PDF telle qu'Adobe Acrobat Pro DC), assurez-vous que les noms des champs de signature contiennent uniquement des lettres et des nombres ou une combinaison des deux. Tous les caractères spéciaux, notamment les lettres accentuées, les points, les barres, etc. ne sont pas pris en charge et ne peuvent pas être utilisés. Les mêmes restrictions s'appliquent au chargement de documents PDF contenant des champs texte.
- L'ajout de plusieurs initiateurs dans un même package n'est pas pris en charge.
- L'application ne prend pas toujours en charge la combinaison des méthodes de signature eID et BeLawyer comme choix de signature : lorsque le paramètre MandatedSigningType a la valeur nameandbirthdate dans l'Index de configuration, ces deux méthodes ne peuvent pas être combinées.
- À l'heure actuelle, les packages ne peuvent pas contenir à la fois des documents XML et PDF sur lesquels des signatures seront apposées. Le type de package est déterminé par le premier document chargé.
- Les groupes par défaut « administrateurs » et « groupe d'utilisateurs par défaut » ne peuvent pas être utilisés comme signataires dans les templates (modèles).
- L'insertion d'une tabulation devant un marqueur texte dans Word n'est pas prise en charge. Aux tabulations préférez les tableaux, colonnes ou zones de texte. Si vous voulez néanmoins utiliser des tabulations, convertissez votre document Word au format PDF avant de le charger.
- Si vous utilisez Safari : après la mise à niveau d'une version antérieure, vous serez invité à fermer votre navigateur. Lorsque vous le rouvrez et que vos onglets précédents ne s'ouvrent pas automatiquement, ne réutilisez pas votre lien d'origine vers la page de signature. Sélectionnez plutôt History > Reopen All Windows From Last Session (Historique > Rouvrir toutes les fenêtres de la session précédente).
- Les applications de conception natives pour le DTP, CAO, etc. peuvent générer des documents très complexes (nombre important d'éléments, vecteurs, images, etc.) Il est dès lors possible que l'application ne puisse pas préparer le document dans un délai raisonnable. Il sera donc impossible d'ajouter ces fichiers à l'environnement de signature (via l'API ou le Portail de documents) en raison de l'expiration du délai imparti. Il n'est pas possible de savoir à l'avance si un document complexe va entraîner ou non une expiration dans la mesure où cela dépend d'un nombre trop important de facteurs. Les applications générant ces types de PDF disposent généralement d'une option pour créer un PDF adapté à une utilisation en ligne. Nous recommandons vivement d'utiliser cette option pour limiter la complexité du document avant son chargement.
Signature itsme
- Lorsque vous utilisez itsme comme méthode de signature, le type cible de vos documents doit être le format PDF/A-1 ou PDF/A-2. C'est à l'administrateur de vérifier que ces formats de sortie sont disponibles dans la solution eSignatures de l'utilisateur et c'est à l'utilisateur de sélectionner le format de sortie correct. Connective ne vérifie pas si le format de sortie correct a été sélectionné pour itsme.
- Lors de l'utilisation de la signature itsme dans des packages via le Portail Web, chaque document du package doit être signé individuellement.
- À l'heure actuelle, la signature itsme n'est pas prise en charge par un système macOS Mojave v10.14 exécutant Safari v12.0.
Preuves d'audit
- La fonction Audit Proof (Preuve d'audit) a une incidence importante sur la base de données eSignatures. Plus les documents sont volumineux, plus ils utiliseront d'espace. Cet impact est proportionnel à la taille des documents.
- La fonction Audit Proof (Preuve d'audit) a aussi un impact sur la vitesse de signature d'eSignatures. Plus les documents sont volumineux, plus il faudra de temps pour la signature. Les petits documents (< 1Mo) se semblent pas avoir d'impact sur la vitesse de signature.
Migration de la version v2 à v3 de l'API
Mode hérité (Legacy)
Si les clients ne sont pas en mesure d'effectuer la mise à niveau vers la version 3 de l'API parce qu'ils ne peuvent pas encore prendre en charge les URL ou les jetons d'accès à usage unique, ils peuvent utiliser le mode hérité (Legacy) en association avec la version 2 de l'API. Le mode hérité est une mesure temporaire qui prend en charge les « anciennes » URL et vous permet de terminer des documents inachevés. Sachez toutefois qu'il s'agit d'une fonctionnalité obsolète qui sera supprimée de la version 4 de l'API.
Les restrictions suivantes sont d'application :
- Lorsque le mode hérité est désactivé dans un environnement et que vous décidez de l'activer par la suite, les flux de l'API qui ont été créés alors que le mode hérité était désactivé ne fonctionneront plus.
- Lorsque le mode hérité est désactivé, les URL de téléchargement extraites de la version 2 de l'API ne peuvent être utilisées qu'une seule fois. Ces URL ne doivent pas être envoyées directement à l'utilisateur final dans un email puisqu'à la seconde ouverture de l'URL, l'utilisateur recevra un message d'erreur. Pour l'éviter, les clients peuvent prendre les mesures suivantes :
- Ils peuvent envoyer un e-mail avec une URL vers leur application de sorte que c'est l'application qui redirige vers l'URL de téléchargement la plus récente obtenue de la version API v2 juste avant la redirection.
- Ils peuvent ajouter « ?fromEmail=true » à l'URL extraite de la version API v2 afin que nous puissions afficher un écran d'erreur invitant l'utilisateur final à entrer son adresse email. Si cette adresse email correspond à un signataire ou un destinataire et que le package/document existe, celui-ci devrait recevoir un email de Connective avec une nouvelle URL opérationnelle.
2. Informations de mise à niveau
Pour les clients qui signent avec des jetons physiques (eID, méthode biométrique avec tablette de signature Wacom, etc.), le package Connective Browser Package doit être mis à niveau vers la version 2.0.6. La mise à niveau sera demandée automatiquement lors de la tentative de signature d’un document.
Si vous disposez d’une version d’eSignatures installée avant la version 5.4.0, référez-vous à la documentation d’installation Connective – eSignatures 5.4.0 – Installation Documentation pour apprendre comment effectuer une mise à niveau vers la version 5.4.