Exploiter la base de vérité
- Nicolas Rueff
La raison d'être des consentements est de savoir si on a le droit de faire tel ou tel traitement. Cette information peut être obtenue par plusieurs moyens décrits ici.
les snippets sont volontairement gardés au plus simple (pas de contrôle d’erreur, de gestion des sessions etc … ).
vous aurez besoin d’un environnement linux disposant de curl et jq pour faire fonctionner les exemples.
Contenu de cette documentation :
En exportant les consentements via l’API
Avec cette approche, on exporte au format json les consentements qui nous intéressent. Cette approche est intéressante si suivie d’une injection dans un ETL quelconque.
Export de la base au format json zippé
À l’issue de cette commande, le répertoire courant contiendra une archive ZIP contenant la base de vérité.
On utilise la route /organisations/{oid}/consents :
/usr/bin/curl --fail --silent \
"https://core.fairandsmart.com/api/organisations/MY_ORG/consents?limit=1000" \
-H "accept: application/zip" \
-H "authorization: Bearer ACCESS_TOKEN" \
-o consents.zipligne 3 : c’est le content-type qui indique à l’API de renvoyer le contenu sous la forme d’une archive ZIP ;
ligne 4 : injecter un jeton d’accès à l’API (access_token, voir Conseils d'utilisation de l'API | Authentification des accès )obtenu plus haut ;
ligne 5 : nom du fichier de sortie ;
Se reporter à la documentation de l’API pour la liste des filtres disponible, pagination, etc …
Export de la base au format json avec filtrage local
À l’issue de cette commande, le répertoire courant contiendra un json avec la liste d’utilisateur ayant répondu OUI à la seconde finalité (id=1) du premier traitement (id=0) de mon modèle de consentement MY_MODELSERIAL.
On utilise la route /organisations/{oid}/consents :
/usr/bin/curl --fail --silent \
"https://core.fairandsmart.com/api/organisations/MY_ORG/consents?limit=1000&serial=MY_MODELSERIAL" \
-H "accept: application/json" \
-H "authorization: Bearer ACCESS_TOKEN" \
| /usr/bin/jq -c '.values[] | select( .value | contains("0-1"))' \
| /usr/bin/jq -c '{"userid": (.author)}' \
| /usr/bin/jq -s . ligne 4 : injecter un jeton d’accès à l’API (access_token, voir Conseils d'utilisation de l'API | Authentification des accès )obtenu plus haut ;
ligne 5 : on ne conserve que les enregistrements contenant “0-1” (= OUI à traitement n°0 / finalité n°1) ;
ligne 6 : on ne conserve que l’utilisateur (= author) ;
ligne 7 : on remets sous la forme d’un tableau JSON ;
Se reporter à la documentation de l’API pour la liste des filtres disponible, pagination, etc …
En interrogeant la base de vérité via l’API
Ici on demande si un utilisateur donné a consenti à un traitement donné. Cet appel ne fonctionne que si la finalité visée référence un traitement :
Les références de traitement associés peuvent être créés et positionnés pendant, mais également après activation d’un modèle.
On utilise la route /organisations/{oid}/treatments/query
/usr/bin/curl --fail --silent \
"https://core.fairandsmart.com/api/organisations/MY_ORG/treatments/query" \
-H "Content-Type: application/x-www-form-urlencoded" \
-H "authorization: Bearer ACCESS_TOKEN" \
--data-binary '{
"organisationId":"MY_ORG",
"treatmentKey":"MY_TREATMENT",
"userId":"THE_USER_ID",
"date":"",
"attributes":{}
}' \
| jq .evaluations[0].evaluationligne 4 : injecter un jeton d’accès à l’API (access_token, voir Conseils d'utilisation de l'API | Authentification des accès )obtenu plus haut ;
ligne 5 : définition du payload ;
ligne 12 : extraction de la réponse (true / false) ;
A l’issue de la commande, on obtient “true” (→ traitement autorisé) ou “false ( → traitement non autorisé);
Se reporter à la documentation de l’API pour la définition du payload.
En exportant les consentements via l’interface
<à venir>
En interrogeant la base de vérité via l’interface
<à venir>