Difference between revisions of "RICM5 2018 2019 - UGAChain - Choix de conception et programmation"
Leo.Valette (talk | contribs) |
Leo.Valette (talk | contribs) |
||
Line 80: | Line 80: | ||
login : string |
login : string |
||
hash : string |
hash : string |
||
− | * <code>/requests/invById?login={login}&transactionID={transactionID}</code> |
||
− | login : string |
||
− | identifiant de transaction : string |
||
| |
| |
||
<span style="color:red">✘</span> Erreur sur le format du hash ou du identifiant fournis par le client : <code>HTTPStatus→EXCEPTION_FAILED (417)</code> |
<span style="color:red">✘</span> Erreur sur le format du hash ou du identifiant fournis par le client : <code>HTTPStatus→EXCEPTION_FAILED (417)</code> |
||
Line 99: | Line 96: | ||
login : string |
login : string |
||
hash : string |
hash : string |
||
− | |||
− | * <code>/requests/revById?login={login}&transactionID={identifiant de transaction}</code> |
||
− | login : string |
||
− | identifiant de transaction : string |
||
| |
| |
||
<span style="color:red">✘</span> Erreur sur le format du hash ou du identifiant fournis par le client : <code>HTTPStatus→EXCEPTION_FAILED (417)</code> |
<span style="color:red">✘</span> Erreur sur le format du hash ou du identifiant fournis par le client : <code>HTTPStatus→EXCEPTION_FAILED (417)</code> |
||
Line 119: | Line 112: | ||
login : string |
login : string |
||
hash : string |
hash : string |
||
− | |||
− | * <code>/requests/fraById?login={login}&transactionID={identifiant de transaction}</code> |
||
− | login : string |
||
− | identifiant de transaction : string |
||
| |
| |
||
<span style="color:red">✘</span> Erreur sur le format du hash ou du identifiant fournis par le client : <code>HTTPStatus→EXCEPTION_FAILED (417)</code> |
<span style="color:red">✘</span> Erreur sur le format du hash ou du identifiant fournis par le client : <code>HTTPStatus→EXCEPTION_FAILED (417)</code> |
||
Line 138: | Line 127: | ||
* <code>/requests/checkByHash?&hash={hash}</code> |
* <code>/requests/checkByHash?&hash={hash}</code> |
||
hash : string |
hash : string |
||
− | |||
− | * <code>/requests/checkByID?&transactionId={transactionId}</code> |
||
− | transactionId : string |
||
| |
| |
||
<span style="color:red">✘</span> Erreur sur le format du hash ou du identifiant fournis par le client : <code>HTTPStatus→EXCEPTION_FAILED (417)</code> |
<span style="color:red">✘</span> Erreur sur le format du hash ou du identifiant fournis par le client : <code>HTTPStatus→EXCEPTION_FAILED (417)</code> |
Revision as of 12:26, 13 March 2019
Cette page est destinée à rassembler tous les choix de conception et de programmation qui ont été fait lors du projet UGAChain 2018-2019.
Choix de conception
Cette partie est à adosser à la page dédiée à la description de la conception du projet.
Prérequis
Diplômant
- Le diplômant conserve la version numérique ou le numéro de transaction de tous les diplômes (pour pouvoir les invalider)
- Le diplômant assure la non reproductibilité d'un diplôme à partir des informations qu'il contient (afin d'éviter une attaque du type construction du diplôme puis requête à UGAChain)
Fonctionnalités implémentées
Vérification de diplôme
Pour des questions de performance, il est intéressant de conserver la fonctionnalité de vérification de diplôme à partir du diplôme sous format numérique et du N° de transaction, sans vérifier une éventuelle transaction d'invalidation qui impliquerait un parcours total de la blockchain. On appelle cela la recherche "légère". Avec cette fonctionnalité vient la question de la réintroduction de la fonctionnalité de récupération du numéro de transaction à partir d'un diplôme, et donc de l'acteur "diplômé".
La deuxième fonctionnalité de vérification à partir du diplôme seulement (qu'on appellerait recherche "profonde"), impliquerait le parcours de la channel d'ajout pour vérifier la présence du diplôme dans la base de données, puis une recherche dans la seconde channel pour en vérifier l'état : valide/invalide.
On a ainsi 2 channels, dans le premier sont stockés uniquement les transactions d'ajout, et dans la deuxième les transactions de changement d'état (invalidation et éventuellement les nouvelles-validations).
Fonctionnement du système
Hashage
On ne hache pas les métadonnées du diplôme (sa validité par exemple) :
- afin de pouvoir invalider un diplôme inséré frauduleusement dans la chaîne de blocs, à partir du hash du diplôme uniquement (récupération du hash du diplôme de la transaction frauduleuse, insertion d'une transaction contenant ce hash avec des métadonnées d'invalidation)
- afin de pouvoir créer des transactions d'anciens diplômes avec de nouvelles métadonnées sans avoir à hacher de nouveau le diplôme (cas d'usage : ajouter une métadonnée à tous les diplômes précédemment insérés dans la chaîne de blocs)
Choix de programmation
API frontend-backend
On passe dans un premier temps les paramètres de l'API dans l’URL, par facilité.
Objets transitant
Vont être communiquées via cette API les informations suivantes :
- Type de requête
Du frontend au backend, passé par le endpoint auquel on accède (en frontend et backend résulte en un enum : ADDITION, INVALIDATION, REVALIDATION, FRAUD_REPORT)
- Hash
Entre le backend et le frontend, string
- État d'un diplôme :
Du backend au frontend, un enum VALID, INVALID, FRAUDULENT donc string : "VALID", "INVALID", "FRAUDULENT" (ou "NOT_FOUND" en cas d'absence dans la blockchain)
- Identifiant de transaction
Entre le backend et le frontend, string (imposé par Hyperledger)
Endpoints
Type | Méthode http | Endpoint | Retour |
---|---|---|---|
Ajout |
POST |
login : string hash : string |
✘ Erreur sur le format du hash ou du identifiant fournis par le client : ✘ Le hash est déjà présent dans la BlockChain : ✘ Erreur côté serveur : ✔ |
Invalidation |
POST |
login : string hash : string |
✘ Erreur sur le format du hash ou du identifiant fournis par le client : ✘ Le hash n'est pas présent dans la BlockChain : ✘ Erreur côté serveur : ✔ |
Revalidation |
POST |
login : string hash : string |
✘ Erreur sur le format du hash ou du identifiant fournis par le client : ✘ Le hash n'est pas présent dans la BlockChain : ✘ Erreur côté serveur : ✔ |
Fraude |
POST |
login : string hash : string |
✘ Erreur sur le format du hash ou du identifiant fournis par le client : ✘ Le hash n'est pas présent dans la BlockChain : ✘ Erreur côté serveur : ✔ |
Check |
GET |
hash : string |
✘ Erreur sur le format du hash ou du identifiant fournis par le client : ✘ Erreur côté serveur : ✔ où
|