OneSpan Sign Release 11.29: Expiration basée sur le temps
OneSpan Sign version 11.29 a récemment été déployé dans l'environnement de prévisualisation et de bac à sable. Dans cette nouvelle version, nous avons continuellement amélioré l'interface utilisateur Signer pour un meilleur support d'accessibilité, activé le paramètre de langue au niveau du compte, fourni un message KBA plus convivial pour les utilisateurs en lock-out, pris en charge l'expiration temporelle pour les transactions et modèles, 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 la nouvelle fonctionnalité d'expiration basée sur le temps. Grâce à ce guide étape par étape, nous allons explorer cette fonctionnalité et mettre en valeur ce qu'il faut attendre de cette amélioration.
Expiration basée sur le temps dans le signe OneSpan
Dans le blog précédent, nous avons discuté de la façon de définir l'heure à laquelle une transaction ou un modèle expirera. Les utilisateurs peuvent désormais définir une date d'expiration simplement en spécifiant un intervalle de temps. Cette fonctionnalité permet aux utilisateurs de spécifier plus facilement l'expiration, en particulier lorsque le flux de travail dépend de modèles et de fuseaux horaires multiples. Pour utiliser cette fonctionnalité, voir la démonstration ci-dessous :
Pour les utilisateurs ad-hoc
Dans l'interface Web, consultez les pages « Création de transaction » et « Transaction Détaillée ». Là, vous trouverez la configuration d'expiration a été ajoutée aux panneaux "SETTINGS". Voir la capture d'écran ci-dessous:
Une liste de déclassement vous fournit les options « Jour »et « Date » et vous permet d'entrer l'intervalle en jours. Cela vous permet de définir une expiration sans avoir à calculer la date souhaitée. Il est également possible d'hériter de la valeur d'un modèle ou du paramètre de niveau du compte. Nous clarifierons ci-dessous.
Pour les utilisateurs d'API RESTful
Ensuite, nous allons enquêter sur le niveau JSON pour voir comment les informations d'expiration peuvent être transmises par API. Il y a en fait deux paramètres de niveau de transaction "defaultTimeBasedExpiry" et "remainingDays" qui ont déterminé l'intervalle de temps, voir l'API de création de paquet ci-dessous:
Demande HTTP
POST /api/packages
En-têtes HTTP
Authentification : base de api_key Type de contenu : application/json Accepter : application/json
Demande de charge utile
{
"statut": "DRAFT",
"description": "Une transaction de test pour la fonction d'expiration basée sur le temps.",
"langue": "en",
"timezoneId": "GMT",
"réglages":
"cérémonie":
"defaultTimeBasedExpiry": vrai,
"jours restants": 15
}
},
"type": "PACKAGE",
"nom": "Test Time based Expiry"
}
Note:
- "defaultTimeBasedExpiry" et "remainingDays" fonctionnent en tandem, alors n'oubliez pas de les régler à la fois lors de l'utilisation de la fonctionnalité.
- C'est l'attribut « dû » qui détermine finalement la date d'expiration. Lors de l'expiration temporelle, la date est automatiquement calculée en ajoutant les jours d'intervalle à la date de création de la transaction.
- Avec l'expiration temporelle déjà fixée ("defaultTimeBasedExpiry" et "remainingDays" attributs) pour votre transaction, si vous voulez toujours changer à l'expiration basée sur la date en spécifiant la date exacte, n'oubliez pas de définir "defaultTimeBasedExpiry" à faux à faux à faux à faux à faux à faux à en même temps que vous mettez à jour la transaction. Cela permettra d'éviter toute confusion potentielle.
Jours d'intervalle par défaut
Paramètres de niveau de compte :
Comprendre l'expiration basée sur le temps est un paramètre de transaction, les valeurs par défaut pour cette configuration peuvent être pré-établies par l'intermédiaire de notre équipe de support en fonction de vos propres besoins. Par conséquent, toutes les transactions nouvellement créées hériteront de ces valeurs et calculeront automatiquement l'attribut « dû » en fonction de la date de création et des jours d'intervalle.
De Templates:
Un des aspects les plus précieux de cette fonctionnalité est que la façon dont elle s'aligne avec un cas d'utilisation modélisé. Si vous utilisez un modèle, il n'est pas logique pour ce modèle de porter une date d'expiration fixe qui serait ensuite recyclé dans les utilisations futures du modèle. Avec cette nouvelle capacité, cependant, toutes les dates d'expiration sont calculées dynamiquement. Lorsque vous créez des transactions à partir d'un modèle existant, elles peuvent hériter d'un intervalle de temps par défaut plutôt que d'une date fixe pour leur expiration.
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!
OneSpan Sign Developer Community
Rejoignez la communauté OneSpan Sign Developer! Forums, blogs, documentation, téléchargements SDK, et plus encore.
Joignez-vous aujourd'hui