Arborescence des pages

Depuis la version 1.11.2 des web services, sous la forme d'API REST, sont disponibles. Esup-Signature propose une documentation automatique disponible sur votre instance à l'adresse "https://<votre adresse>/swagger-ui.html"

La documentation est aussi consultable (mais non testable...) sur le site de démonstration à cette adresse :

https://esup-signature-demo.univ-rouen.fr/swagger-ui.html

Securité des web services

L'accès aux web services est filtré par IP. Pour autoriser l'accès il faut modifier la configuration en ajoutant l'IP de la machine concernée au niveau du paramètre ws-access-authorize-ips ici :

Configuration#security.1

Sécurisation par tokens

Depuis la version 1.29.x il est possible d'attribuer des tokens par workflows ou des tokens "wildcard" (donne accès à toutes les demandes). Mais si l'on utilise le système de tokens, il faut toujours autoriser L'IP du serveur distance dans ws-access-authorize-ips

Si aucun token n'est défini c'est le mode par IP qui fonctionne (comme c'était le cas avant)


Au niveau de l'interface admin il suffit d'ajouter des tokens dans "Token API": 

On donne un nom au token est on selectionne le/les circuit(s) concerné(s)

Ici on a deux type de token : "Tous les workflows" et un pour un circuit en particulier.

Lorsque d'un circuit est protégé par un token, l'IP ne suffit plus pour acceder aux demandes qu'il contient.

Il faut alors ajouter l'attribut X-API-Key contenant la clé, dans le header de la requête du client.

Voici un exemple de récupération d'une demande via curl:

curl --location --request GET 'http://dsi-7.univ-rouen.fr/ws/signrequests/23152' \
--header 'X-API-Key: ede824ef-7eea-4949-b9d3-427aa1b38baf'

Si vous utilisez une clé "wildcard", vous pourrez acceder à toutes les demandes quelque soit le circuit.

Tester les web services

Curl

Les web services d'esup-signature étant au format REST, il est possible de les tester à l'aide de commandes curl. Des exemples sont proposés dans cette documentation ainsi de dans la documentation swagger. De plus, il est possible de tester les web services directement depuis l'interface swagger. (Dans esup-signature Admin → APIs Doc)

Swagger

Il est possible de tester les web services directement depuis votre interface swagger https://<adresse esup signature>/swagger-ui.html . Pour cela il faut être admin et il faut modifier la valeur  supported-submit-methods dans application.yml

supported-submit-methods: ["get", "put", "post"]

Les circuits nécessitant l'envoi d'un fichier (multipart files) ne peuvent pas être testés directement via l'interface swagger

Postman

Postman est très pratique pour tester l'envoi de fichier dans un circuit (multiples fichiers acceptés). Ex :

Dans tous les cas la/les machine(s) qui exécutent les web service (directement, via commandes curl ou qui utilise swagger) doivent être déclarées dans la configuration d'esup-signature. L'accès aux web services permet d'effectuer beaucoup d'actions il est donc sécurisé par adresse IP, à configurer dans src/main/resources/application.yml au niveau du paramètres : ws-access-authorize-ips



Fonctionnement général

La première étape pour utiliser les web services est de créer un circuit au niveau de l'administration.

En général, c'est à l'appel du web service que l'on va configurer les signataires, il faudra donc créer autant d'étapes que l'on souhaite en laissant la liste des participants vide (sauf dans le cas ou une des étapes possède un signataire fixe).

Voici comment est configurée ce type d'étape :

Dans l'onglet paramètres du circuit, vous n'avez pas besoin de configurer d'autorisation (le circuit ne sera pas visible sur la page d'accueil). Sur cette page, vous retrouvez l'id qu'il faudra utiliser au lancement du web service (ici 108) :


Une fois l'appel web service effectué, celui-ci vous retourne les identifiants des demandes (un par document envoyer) séparés par des virgules.

Ces identifiants doivent être conservés par l'application métier afin de permettre un suivi de l'avancement par celle-ci.

Afin de cloturer une demande en fin de circuit, il y a deux possibilité :

  1. L'application métier, qui a poussé le document, vient régulièrement controler son statut en utilisant le web service /ws/signrequests/{id} avec l'id de la demande concernée (le retour peut etre pending, completed, refused, deleted ou  fully_deleted)
  2. Esup-signature appel un web service fourni par l'application métier. Dans ce cas il faut ajouter une destination au niveau des paramètres du circuit en y mettent l'url du web service de l'application metier. À la fin du circuit, esup-signature enverra un simple GET à votre adresse suivi de :
    ?signRequestId=<id>&status=<statut>

Enfin l'application métier pourra supprimer le document en faisant une requete DELETE sur l'adresse /ws/signrequests/{id}. Les éléments de vérification de la signature sont conservés dans esup-signature.



Le paramètre stepsJsonString

Depuis la version 1.28 vous pouvez passer une liste de "WorkflowStepDto" (https://github.com/EsupPortail/esup-signature/blob/master/src/main/java/org/esupportail/esupsignature/dto/WorkflowStepDto.java), dans tous les web services de création, pour configurer vos étapes.

Cela remplace les paramètres recipientEmails, signTypes, allSignToCompletes, etc., mais la rétrocompatibilité est maintenue.

Le JSON à transmettre doit représenter le même nombre d'étapes que celle présente dans le circuit configuré dans l'interface admin. La numérotation des steps (stepNumber) est obligatoire est démarre du chiffre 1.

[
{
  "title": "string",
  "stepNumber": 1,
  "description": "string",
  "recipientsCCEmails": [
    "string"
  ],
  "recipients": [
    {
      "email": "string",
      "phone": "string",
      "name": "string",
      "firstName": "string",
      "forceSms": true
    }
  ],
  "changeable": false,
  "signLevel": 0,
  "signType": "hiddenVisa",
  "repeatable": false,
  "repeatableSignType": "hiddenVisa",
  "allSignToComplete": true,
  "multiSign": true,
  "autoSign": false,
  "forceAllSign": true,
  "comment": "string",
  "attachmentRequire": true,
  "maxRecipients": 0
}
]

Exemple:

[{"title":"test1","stepNumber": 1,"description": "test1","recipients": [{"email": "toto@univ-ville.fr"}],"signLevel": 0,"signType": "pdfImageStamp", "allSignToComplete": true},{"title": "test2","stepNumber": 2,"description": "test2","recipients": [{"email": "titi@gmail.fr","phone": "0123456789","name":"Tata","firstName": "Titi"}],"signLevel": 0,"signType": "pdfImageStamp","allSignToComplete": true}]



Exemples

Démarrer un formulaire

Accès : https://<votre adresse>/ws/forms/{id}/new

Description : Ce web service va créer une nouvelle instance du formulaire désigné pas le paramètre "id" de l'url d'accès.

Attributs : 

AttributDescription

createByEppn

eppn du propriétaire du futur document
stepsJsonString

Si les participants de certaines étapes sont configurables, il faut saisir un tableau de WorkflowStepDto[].

Ex :

[{"signType":"pdfImageStamp", "recipients": [{"email": "test.test@univ-ville.fr"}, {"email": "test2.test2@univ-ville.fr"}]},

{"signType":"certSign", "recipients": [{"email": "test.test@univ-ville.fr"}, {"email": "test2.test2@univ-ville.fr"}]}]

targetEmailsPour que la demande soit transmise par à la fin du circuit, il est possible, d'envoyer un tableau de String contenant la liste des destinataires finaux
targetUrlurl pour la destination finale des formulaire terminés. Ex : smb://stockage.univ-ville.fr/form

Exemple de commande curl :

curl --location --request POST 'http://dsi-7.univ-rouen.fr/ws/signrequests/new' \
--form 'multipartFiles=@"/home/lemaida3/Documents/sample.pdf"' \
--form 'createByEppn="test@univ-ville.fr"' \
--form 'stepsJsonString="[{\"signType\":\"pdfImageStamp\", \"recipients\": [{\"email\": \"david.lemaignent@univ-rouen.fr\"}, {\"email\": \"demo.esup@inv.univ-rouen.fr\"}]},
{\"recipients\": [{\"email\": \"david.lemaignent@univ-rouen.fr\"}, {\"email\": \"demo.esup@inv.univ-rouen.fr\"}]}]"'


Envoyer un document dans un circuit existant


Accès : https://<votre adresse>/ws/workflows/{id}/new

Description : Ce web service va déposer d'un document dans une nouvelle instance d'un circuit

Attributs : 

AttributDescription
multipartFile (obligatoire)

Multipart stream du fichier à signer

createByEppn (obligatoire)eppn du propriétaire du futur document
stepsJsonString

Si les participants de certaines étapes sont configurables, il faut saisir un tableau de WorkflowStepDto[].

Ex :

[{"signType":"pdfImageStamp", "recipients": [{"email": "test.test@univ-ville.fr"}, {"email": "test2.test2@univ-ville.fr"}]},

{"signType":"certSign", "recipients": [{"email": "test.test@univ-ville.fr"}, {"email": "test2.test2@univ-ville.fr"}]}]

targetEmailsPour que la demande soit transmise par à la fin du circuit, il est possible, d'envoyer un tableau de String contenant la liste des destinataires finaux
targetUrlurl pour la destination finale des formulaire terminés. Ex : smb://stockage.univ-ville.fr/form

Exemple de commande curl :

curl --location --request POST 'https://esup-signature.univ-rouen.fr/ws/workflows/999999/new' \
--form 'createByEppn="test@univ-rouen.fr"' \
--form 'title="TITRE"' \
--form 'multipartFiles=@"/home/lemaida3/Documents/esup-signature/sample.pdf"' \
--form 'recipientsJsonString="[{\"signType\":\"pdfImageStamp\", \"recipients\": [{\"email\": \"test.test@univ-ville.fr\"}, {\"email\": \"test2.test2@univ-ville.fr\"}]},
{\"signType\":\"certSign\", \"recipients\": [{\"email\": \"test.test@univ-ville.fr\"}, {\"email\": \"test2.test2@univ-ville.fr\"}]}]";type=application/json'



  • Aucune étiquette

Commentaire

  1. CARE XAVIER dit :

    Si vous avez plusieurs adresses IP pour les web services, la syntaxe YAML est la suivante (attention, pas de tabulations) :

    ws-access-authorize-ips:
        - 127.0.0.1
        - IP1
        - IP2
        - IP3