/
Example of form generation with curl

Example of form generation with curl

Owned by Victor Guillaume (Deactivated)
Last updated: Mar 05, 2021
3 min read

Before embarking on integration work, it is possible to test form generation with a few commands.

Contents of this documentation:

Preparation

To complete this tutorial, you will need:

  • a member account of your organisation: this can be your own account, or a technical account created for this purpose: see on this subject Invite a new member ;

  • the ID of your organisation: you will find it in Administration >> Organisation:

  • the alias of the form template to call: you will find it in Right Consents >> Configuration >> Consent forms:

You will also need curl, grep, sed.

Call kinematics


The kinematics take place in four steps:

  • obtaining a request token from the authentication backend;

  • obtaining a consent collection URL;

  • submission of the consent form;

  • verification of the submission of the consent form.

Positioning of the environment

Based on the inputs, the variables that will be used in subsequent calls are set.

AUTH_HOST=https://auth.fairandsmart.com AUTH_REALM=FairAndSmart AUTH_CLIENTID=fsorg AUTH_USER=UTILISATEUR@DOMAINE.TLD AUTH_PASS=MOT_DE_PASSE API_HOST=https://core.fairandsmart.com ORGANISATION_ID=ORGANISATION_ID MODEL_ALIAS=ALIAS_DU_MODELE USER_ID=USERID_ARBITRAIRE

Obtaining a request token from the authentication backend

The route to call is /protocol/openid-connect/token in the FairAndSmart realm on the authentication directory.

Here, you only need to obtain an access token, with a short validity period. In production, it is advisable to use an OAuth client allowing to obtain a refresh token - with long validity - from the login/password, then to use it to retrieve an access token.

Example using shell with curl:

RESPONSE=$(curl --fail --silent $AUTH_HOST/auth/realms/$AUTH_REALM/protocol/openid-connect/token \ --header "Content-Type: application/x-www-form-urlencoded" \ --data-urlencode "username=$AUTH_USER" \ --data-urlencode "password=$AUTH_PASS" \ --data-urlencode 'grant_type=password' \ --data-urlencode "client_id=$AUTH_CLIENTID" \ ) ACCESS_TOKEN=$(echo $RESPONSE | sed 's/.*"access_token":"\([^"]\+\)".*/\1/g') echo "access token : $ACCESS_TOKEN"

Obtaining a consent collection URL

The route to call is /organisations/$ORGANISATION_ID/consents/$MODEL_ID/endpoint on the generation backend, providing the previously generated token in a "bearer" type "Authentication" header.

 

Example using shell with curl:

RESPONSE=$(curl --fail --silent "$API_HOST/api/organisations/$ORGANISATION_ID/consents/$MODEL_ALIAS/endpoint" \ --header "Authorization: Bearer $ACCESS_TOKEN" \ --header 'Content-Type: application/json' \ --data-binary '{"userid":"$USER_ID","language":"fr"}' \ ) CONSENT_URL=$(echo $RESPONSE | sed 's/.*"endpoint":"\([^"]\+\)".*/\1/g') echo "consent url : $CONSENT_URL"

Submission of the consent form

The same type of request is constituted as that which could be carried out from a web browser, via a preliminary operation of extracting the hidden field containing the authentication token of the form.


Example using shell with curl:

Verification of the submission of the consent form

The route to call is /organisations/$ORGANISATION_ID/consents on the generation backend, indicating the user concerned and providing the previously generated token in a "bearer" type "Authentication" header.

 

The complete snippet (shell / curl)

 

deliberately left basic in its approach, do not use in production

 

To find out more