mirror of
https://github.com/ae-utbm/sith.git
synced 2025-06-07 19:55:20 +00:00
api key doc for developers
This commit is contained in:
parent
65d43caf15
commit
2dd28a37ab
@ -41,7 +41,7 @@ et de la méthode d'authentification.
|
||||
Vous pouvez vous connecter directement sur l'interface Swagger,
|
||||
en cliquant sur ce bouton, en haut à droite :
|
||||
|
||||

|
||||

|
||||
/// caption
|
||||
Bouton d'autorisation sur Swagger
|
||||
///
|
||||
@ -50,7 +50,7 @@ Puis rentrez votre clef d'API dans le champ prévu à cet effet,
|
||||
et cliquez sur authorize :
|
||||
|
||||
|
||||

|
||||

|
||||
/// caption
|
||||
Saisie de la clef d'API
|
||||
///
|
132
docs/tutorial/api/dev.md
Normal file
132
docs/tutorial/api/dev.md
Normal file
@ -0,0 +1,132 @@
|
||||
|
||||
Pour l'API, nous utilisons `django-ninja` et sa surcouche `django-ninja-extra`.
|
||||
Ce sont des librairies relativement simples et qui présentent
|
||||
l'immense avantage d'offrir des mécanismes de validation et de sérialisation
|
||||
de données à la fois simples et expressifs.
|
||||
|
||||
## Schéma de données
|
||||
|
||||
Le cœur de django-ninja étant sa validation de données grâce à Pydantic,
|
||||
le développement de l'API commence par l'écriture de ses schémas de données.
|
||||
|
||||
Pour en comprendre le fonctionnement, veuillez consulter
|
||||
[la doc de django-ninja](https://django-ninja.dev/guides/response/).
|
||||
|
||||
Il est également important de consulter
|
||||
[la doc de pydantic](https://docs.pydantic.dev/latest/).
|
||||
|
||||
Notre surcouche par-dessus les schémas de django-ninja est relativement mince.
|
||||
Elle ne comprend que [UploadedImage][core.schemas.UploadedImage], qui hérite de
|
||||
[`UploadedFile`](https://django-ninja.dev/guides/input/file-params/?h=upl)
|
||||
pour le restreindre uniquement aux images.
|
||||
|
||||
## Authentification et permissions
|
||||
|
||||
### Authentification
|
||||
|
||||
Notre API offre deux moyens d'authentification :
|
||||
|
||||
- par cookie de session (la méthode par défaut de django)
|
||||
- par clef d'API
|
||||
|
||||
La plus grande partie des routes de l'API utilisent la méthode par cookie de session.
|
||||
|
||||
Pour placer une route d'API derrière l'une de ces méthodes (ou bien les deux),
|
||||
utilisez l'attribut `auth` et les classes `SessionAuth` et
|
||||
[`ApiKeyAuth`][apikey.auth.ApiKeyAuth].
|
||||
|
||||
!!!example
|
||||
|
||||
```python
|
||||
@api_controller("/foo")
|
||||
class FooController(ControllerBase):
|
||||
# Cette route sera accessible uniquement avec l'authentification
|
||||
# par cookie de session
|
||||
@route.get("", auth=[SessionAuth()])
|
||||
def fetch_foo(self, club_id: int): ...
|
||||
|
||||
# Et celle-ci sera accessible peut importe la méthode d'authentification
|
||||
@route.get("/bar", auth=[SessionAuth(), ApiKeyAuth()])
|
||||
def fetch_bar(self, club_id: int): ...
|
||||
```
|
||||
|
||||
### Permissions
|
||||
|
||||
Si l'utilisateur est connecté, ça ne veut pas dire pour autant qu'il a accès à tout.
|
||||
Une fois qu'il est authentifié, il faut donc vérifier ses permissions.
|
||||
|
||||
Pour cela, nous utilisons une surcouche
|
||||
par-dessus `django-ninja`, le système de permissions de django
|
||||
et notre propre système.
|
||||
Cette dernière est documentée [ici](../perms.md).
|
||||
|
||||
### Limites des clefs d'API
|
||||
|
||||
Le système des clefs d'API est apparu très tard dans l'histoire du site
|
||||
(en P25, 10 ans après le début du développement).
|
||||
Il s'agit ni plus ni moins qu'un système d'authentification parallèle fait maison,
|
||||
devant interagir avec un système de permissions ayant connu lui-même
|
||||
une histoire assez chaotique.
|
||||
|
||||
Assez logiquement, on ne peut pas tout faire :
|
||||
il n'est pas possible que toutes les routes acceptent
|
||||
l'authentification par clef d'API.
|
||||
|
||||
Cette impossibilité provient majoritairement d'une incompatibilité
|
||||
entre cette méthode d'authentification et le système de permissions
|
||||
(qui n'a pas été prévu pour l'implémentation d'un client d'API).
|
||||
Les principaux points de friction sont :
|
||||
|
||||
- `CanView` et `CanEdit`, qui se basent `User.can_view` et `User.can_edit`,
|
||||
qui peuvent eux-mêmes se baser sur les méthodes `can_be_viewed_by`
|
||||
et `can_be_edited_by` des différents modèles.
|
||||
Or, ces dernières testent spécifiquement la relation entre l'objet et un `User`.
|
||||
Ce comportement est possiblement changeable, mais au prix d'un certain travail
|
||||
et au risque de transformer encore plus notre système de permissions
|
||||
en usine à gaz.
|
||||
- `IsSubscriber` et `OldSubscriber`, qui vérifient qu'un utilisateur est ou
|
||||
a été cotisant.
|
||||
Or, une clef d'API est liée à un client d'API, pas à un utilisateur.
|
||||
Par définition, un client d'API ne peut pas être cotisant.
|
||||
- `IsLoggedInCounter`, qui utilise encore un autre système
|
||||
d'authentification maison et qui n'est pas fait pour être utilisé en dehors du site.
|
||||
|
||||
## Créer un client et une clef d'API
|
||||
|
||||
Le site n'a actuellement pas d'interface permettant à ses utilisateurs
|
||||
de créer une application et des clefs d'API.
|
||||
|
||||
C'est volontaire : tant que le système ne sera pas suffisamment mature,
|
||||
toute attribution de clef d'API doit passer par le pôle info.
|
||||
|
||||
Cette opération se fait au travers de l'interface admin.
|
||||
|
||||
Pour commencer, créez un client d'API, en renseignant son nom,
|
||||
son propriétaire (l'utilisateur qui vous a demandé de le créer)
|
||||
et les groupes qui lui sont attribués.
|
||||
Ces groupes sont les mêmes que ceux qui sont attribués aux utilisateurs,
|
||||
ce qui permet de réutiliser une partie du système d'authentification.
|
||||
|
||||
!!!warning
|
||||
|
||||
N'attribuez pas les groupes "anciens cotisants" et "cotisants"
|
||||
aux clients d'API.
|
||||
Un client d'API géré comme un cotisant, ça n'a aucun sens.
|
||||
|
||||
Evitez également de donner à des clients d'API des droits
|
||||
autres que ceux de lecture sur le site.
|
||||
|
||||
Et surtout, n'attribuez jamais le group Root à un client d'API.
|
||||
|
||||
Une fois le client d'API créé, créez-lui une clef d'API.
|
||||
Renseignez uniquement son nom et le client d'API auquel elle est lié.
|
||||
La valeur de cette clef d'API est automatiquement générée
|
||||
et affichée en haut de la page une fois la création complétée.
|
||||
|
||||
Notez bien la valeur de la clef d'API et transmettez-la à la personne
|
||||
qui en a besoin.
|
||||
Dites-lui bien de garder cette clef en lieu sûr !
|
||||
Si la clef est perdue, il n'y a pas moyen de la récupérer,
|
||||
vous devrez en recréer une.
|
||||
|
||||
|
@ -66,7 +66,9 @@ nav:
|
||||
- Gestion des permissions: tutorial/perms.md
|
||||
- Gestion des groupes: tutorial/groups.md
|
||||
- Les fragments: tutorial/fragments.md
|
||||
- Connexion à l'API: tutorial/connect-api.md
|
||||
- API:
|
||||
- Développement: tutorial/api/dev.md
|
||||
- Connexion à l'API: tutorial/api/connect.md
|
||||
- Etransactions: tutorial/etransaction.md
|
||||
- How-to:
|
||||
- L'ORM de Django: howto/querysets.md
|
||||
|
Loading…
x
Reference in New Issue
Block a user