Refactor permissions #35
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #35 +/- ##
===========================================
- Coverage 94.16% 79.96% -14.20%
===========================================
Files 86 113 +27
Lines 1594 1832 +238
Branches 324 343 +19
===========================================
- Hits 1501 1465 -36
- Misses 83 362 +279
+ Partials 10 5 -5 ☔ View full report in Codecov by Sentry. 🚨 Try these New Features:
|
| ``` | ||
|
|
||
| **Exemple :** prenons l'exemple de l'intégration : ils auront : | ||
| * Une _clé API_ pour le pour se connecter au front de EtuUTT avec le compte `[email protected]` (reliée à l'_application_ `EtuUTT-front`) |
There was a problem hiding this comment.
| * Une _clé API_ pour le pour se connecter au front de EtuUTT avec le compte `[email protected]` (reliée à l'_application_ `EtuUTT-front`) | |
| * Une _clé API_ pour se connecter au front de EtuUTT avec le compte `[email protected]` (reliée à l'_application_ `EtuUTT-front`) |
|
|
||
| **Exemple :** prenons l'exemple de l'intégration : ils auront : | ||
| * Une _clé API_ pour le pour se connecter au front de EtuUTT avec le compte `[email protected]` (reliée à l'_application_ `EtuUTT-front`) | ||
| * Une _clé API_ pour le back de leur site web (reliée à `Integration-website`) |
There was a problem hiding this comment.
ça dépend non ? pourquoi il ne pourrait pas y avoir une key/user si on veut accéder à des données privées des utilisateurs par exemple ?
There was a problem hiding this comment.
Ça serait le cas sur une application, sur un site web autant juste donner des permissions à la clé
| **Exemple :** prenons l'exemple de l'intégration : ils auront : | ||
| * Une _clé API_ pour le pour se connecter au front de EtuUTT avec le compte `[email protected]` (reliée à l'_application_ `EtuUTT-front`) | ||
| * Une _clé API_ pour le back de leur site web (reliée à `Integration-website`) | ||
| * Une _clé API_ par utilisateur de leur application (qui n'utiliserait pas le backend de leur site web), avec uniquement les droits de base, pour leur application (reliées à `Integration-app`). Chaque _clé API_ a des permissions différentes, ce qui signifie qu'on peut donner des droits à un utilisateur en particulier sur l'_application_ de l'intégration. |
There was a problem hiding this comment.
A reformuler, comme ça si j'ai bien compris
| * Une _clé API_ par utilisateur de leur application (qui n'utiliserait pas le backend de leur site web), avec uniquement les droits de base, pour leur application (reliées à `Integration-app`). Chaque _clé API_ a des permissions différentes, ce qui signifie qu'on peut donner des droits à un utilisateur en particulier sur l'_application_ de l'intégration. | |
| * Une _clé API_ par utilisateur de leur application mobile, avec uniquement les droits de base (clés reliées à `Integration-app`). Chaque _clé API_ a des permissions différentes, ce qui signifie que chaque utilisateur peut accorder des droits différents à l'_application_ de l'intégration. |
| Une _clé API_ (ou _Api Key_) est une relation entre un utilisateur et une _application_. Un utilisateur ne peut avoir qu'une _clé API_ par _application_. | ||
|
|
||
| ```{note} | ||
| Une _clé API_ **n'est pas** un token, c'est plutôt un objet qui servira à générer un token et authentifier les requêtes. |
There was a problem hiding this comment.
Peut être rappeler que les applis agissent "on the behalf of the user" et que l'utilisateur doit avoir les permissions afin que la clé puisse accéder à la dite permission. (eg. modérer les commentaires, etc)
| ```{note} | ||
| Une _clé API_ **n'est pas** un token, c'est plutôt un objet qui servira à générer un token et authentifier les requêtes. | ||
|
|
||
| Un utilisateur n'a pas nécessairement les mêmes droits sur les différentes _applications_. Il est tout de même important de noter que rien ne l'empêchera d'utiliser une _clé API_ sur une _application_ qui n'est pas liée à cette _clé API_. Il est donc important **d'avoir confiance** en l'utilisateur, et pas uniquement en l'application. |
There was a problem hiding this comment.
| Un utilisateur n'a pas nécessairement les mêmes droits sur les différentes _applications_. Il est tout de même important de noter que rien ne l'empêchera d'utiliser une _clé API_ sur une _application_ qui n'est pas liée à cette _clé API_. Il est donc important **d'avoir confiance** en l'utilisateur, et pas uniquement en l'application. | |
| Un utilisateur peut ne pas accorder les mêmes droits aux différentes _applications_. Il est important de noter que rien ne l'empêchera d'utiliser une _clé API_ sur une _application_ qui n'est pas liée à cette _clé API_. Il est donc important **d'avoir confiance** en l'utilisateur, et pas uniquement en l'application. |
Mais sinon, on peut imaginer un travail de déchiffrement de la clé renvoyée par l'api du site étu. Mais ça veut dire que les requêtes doivent passer par un backend intermédiaire
There was a problem hiding this comment.
Par rapport au requested change, nope, c'est pas ça, c'est pas l'user qui donne des perms a sa clé api, c'est les gens concernés (admins, autres utilisateurs, ou lui dans le cas spécifique du front-end)
|
|
||
| On va traiter l'authentification des requêtes avant la connexion, le _flow_ me paraît plus logique dans ce sens là 🙂 | ||
|
|
||
| Pour authentifier les requêtes, on utilise un _bearer token_ (token JWT), passé dans le _header_ `Authorization`, sous le format `Bearer {token}`. Une fois décodé, le token renvoit un objet contenant un champ `token`. Ce champ permet de trouver une `ApiKey` unique. À partir de cette `ApiKey`, il est ainsi possible d'obtenir l'utilisateur authentifié, et les routes ou informations auxquelles l'utilisateur a le droit d'accéder. |
There was a problem hiding this comment.
Allez c'est cadeau
| Pour authentifier les requêtes, on utilise un _bearer token_ (token JWT), passé dans le _header_ `Authorization`, sous le format `Bearer {token}`. Une fois décodé, le token renvoit un objet contenant un champ `token`. Ce champ permet de trouver une `ApiKey` unique. À partir de cette `ApiKey`, il est ainsi possible d'obtenir l'utilisateur authentifié, et les routes ou informations auxquelles l'utilisateur a le droit d'accéder. | |
| Pour authentifier les requêtes, on utilise un _bearer token_ (token JWT), passé dans le _header_ `Authorization`, sous le format `Bearer {token}`. Une fois décodé, le token renvoie un objet contenant un champ `token`. Ce champ permet de trouver une `ApiKey` unique. À partir de cette `ApiKey`, il est ainsi possible d'obtenir l'utilisateur authentifié, et les routes ou informations auxquelles l'utilisateur a le droit d'accéder. |
|
|
||
| ## Connexion | ||
|
|
||
| On fera la différence entre un utilisateur et une _application_. Mais comme vous avez dû le comprendre, un utilisateur n'est rien d'autre que l'_application_ du site web de EtuUTT essayant de se connecter en tant que cet utilisateur. |
There was a problem hiding this comment.
Vous avez du le comprendre est mal placé puisque tu n'as pas encoré précisé les différentes façons de se connecter
There was a problem hiding this comment.
Ouais mais avec le fonctionnement que j'ai expliqué plus tot, c'est pas une conclusion logique ?
|
|
||
| La méthode de connexion "utilisateur" permettra donc de générer un _bearer token_ temporaire, avec une connexion standard (décentralisée, nom d'utilisateur / mot de passe). | ||
|
|
||
| La méthode de connexion "application" permettra de générer un _bearer token_ avec une durée de vie possiblement infinie (en fonction de ce que veut l'utilisateur). On passe ici par une autre application (le site EtuUTT) pour générer un _bearer token_. |
There was a problem hiding this comment.
J'ai un problème avec cette durée de vie de token potentiellement infinie... C'est contraire a plein de règles de sécurité. Alors oui ça permet d'éviter d'avoir à se reconnecter mais il serait plus sécuritaire de renouveler régulièrement le jwt - automatiquement de façon complètement transparente, par exemple en renvoyant un header spécifique avec la réponse ou de trouver une façon de le rotate - plutôt que de pouvoir lui donner une durée de vie infinie...
Si un token arrive à expiration, l'application refait la demande de connexion à l'application dont la clé émane. Si l'utilisateur est connecté, le token est regen instant sinon il doit rentrer ses identifiants, seems legit
There was a problem hiding this comment.
C'était pas vraiment pour ce cas là, c'était plus pour les applis ou on a la flm de modifier les env vars tous les 4 matins
|
|
||
| ### Pour une application | ||
|
|
||
| Pour une application, on génère un token pour la _clé API_ demandée, puis on retourne le _bearer token_ associé. Il faut aussi bien sauvegarder la date de dernière mise à jour (`tokenUpdatedAt`), et utiliser cette date pour toujours retourner la même version du token (champ `iat` dans l'objet à encoder avec JWT). |
There was a problem hiding this comment.
Rajouter le nom de la table avec tokenUpdatedAt
Maintenant (je pense que j'aurai la réponse quand je lirai le code) mais j'imagine que c'est pour mitiger le fait que la durée de vie puisse être infinie:
- soit en pouvant "supprimer" des tokens qui auraient fuité. Sauf que du coup c'est pas préventif et ça présuppose que des données ont déjà fuité
- soit en regénérant les tokens à chaque connexion de l'utilisateur. Mais ça, ça part du principe que l'app est bien faite et que le dev n'était pas un flemmard qui aurait juste mis une durée de token infinie sans jamais faire se reconnecter les utilisateurs
There was a problem hiding this comment.
Sinon sur tout ce qui est route login, on empêche le token d'être infini ? Et sur les routes de gestion des api keys, on leur permet ?
|
|
||
| Le _bearer token_ est une chaîne de caractère encodant une certaine _clé API_, en utilisant le standard JWT. | ||
|
|
||
| ### Soft grant |
There was a problem hiding this comment.
J'ai définitivement pas compris l'idée d'avoir une clé unique pour une application avec des soft grants et hard grants au lieu d'avoir une clé pour chaque utilisateur. De cette façon. Les fois où l'appli n'a pas besoin de faire une opération en tant qu'un utilisateur particulier (ex. accéder au profil de Jean-Patrick en étant connecté en tant que le dit Jean-Patrick), et bien ça n'arrive pas puisque ces données là sont publiques ? Et si jamais une appli devait accéder à une section privée du site étu (les commentaires des UEs par exemple) et à y donner accès sans login dans ce cas le developpeur n'a cas générer une key et faire accéder son site/app on his behalf, même s'il ne devrait théoriquement pas avoir le droit de le faire (puisque si une appli fait fuiter les commentaires des UEs qui ne sont pas censés être visibles des enseignants, c'est gênant)
Si c'est au niveau du stockage du token, ce token peut rester sur le front en soit et même ça pourrait être le front lui même qui effectuerait ces requêtes ? (je suis pas sûr de l'idée) ou sinon stocké dans la session côté serveur (et transmis lors de la connexion via le site étu) ou sinon mis dans une db (ce qui ne serait pas une guideline)
There was a problem hiding this comment.
Les données des utilisateurs sont pas publiques 😅
Checkez le README, si ce n'est pas clair dites-le moi :)