L'isomorphisme par l'exemple
Gestion des droits end to end
Besoin initial
- système de gestion des accès à l'API REST
- présenter une interface dédiée pour chaque profil utilisateur
1. Gestion des accès API
Accès à une API REST
Formule magique :
Accès (Requête, Profil)
Définition des règles d'accès
Tuples URL/méthodes
[{
path: '/organisations/:organisation_id/users',
methods: ['GET', 'POST']
}, {
path: '/organisations/:organisation_id/users/:user_id',
methods: ['GET', 'PUT', 'DELETE']
}, {
path: '/organisations/:organisation_id/users/([0-9a-f]{24})',
methods: ['GET']
}]
URL templatées
Varient selon le profil authentifié
(utilisation de regexp-tpl & miniquery)
Demo
Hack de angular-beer de @JBPionnier
(back)
2. Interface personnalisée
Solutions envisagées
- Fork du code de l'interface : peu évolutif, source d'erreurs et d'incohérences.
- Affichage conditionnel avec table de droits pré-établis : rend la problématique rémanente.
And the winner is!
L'isomorphisme !
Avantages de l'isomorphisme
- on transmet uniquement l'information, la logique est dupliquée à chaque extrêmité
- facile à mettre en oeuvre dans une stack full JS (ou presque)
- pas de divergence possible entre front et back (ou presque)
Démo
angular-beer defacé ;)
Real world démo
En prod chez @SimpliField
Imperfections
AngularJS
- le système de modules d'Angular est une horreur
- plus de calculs côté front (possible saturation sur appareils peu performants).
- plus généralement, Angular n'est pas fait pour l'isomorphisme
Approche reaccess
- limité aux tuples URL/méthode (quid des entêtes ?)
- trop simpliste (pas de composabilité des règles d'accès)
What's next?
Résolu !
- Composabilité grâce à des règles à la IPTables (ACCEPT, DROP ...)
- tests sur un objet contenant URL, méthode et entêtes
Encore du chemin
- pas encore transposé pour AngularJS
- templating des règles non effectif
- pas encore passé l'épreuve du feu
Ouvert aux contributions
Merci !
(questions ?)