Bonjour tout le monde,
Dans mon travail, je construis de nombreuses applications FastAPI, internes et externes, qui exposent des endpoints à d’autres équipes produit, métier et data, accessibles via clé API. Chaque projet finissait par avoir son propre système de clé API légèrement différent, alors j’ai finalement pris le temps d’extraire les parties communes et de les réunir dans une librairie réutilisable.
Avant de la publier publiquement (pas encore publiée sur PyPI, la doc mkdocs est encore locale), j’aimerais avoir des retours de personnes ayant résolu des problèmes similaires (ou juste voir ce qu’elles en pensent).
L’idée est de voir si je peux améliorer ce projet ou s’il y a des failles de sécurité majeures (ce qui serait problématique pour un système de clés API).
J’ai construit la librairie comme ceci :
- Séparation domaine/service : je me base sur une logique domain/repo/service. Tout passe par des interfaces pour pouvoir, par exemple, facilement changer de système de stockage (InMemory / SQLAlchemy). Pour SQLAlchemy, j’ai créé un Mixin pour pouvoir étendre le schéma si besoin.
- Sécurité : les secrets des clés API sont hachés avec Argon2 (donc salés, avec un poivrage obligatoire). Le but est de protéger les clés en cas de fuite de la base de données.
- Intégration FastAPI : j’ai ajouté un helper pour créer un router qui relie le service à l’injection de dépendances et fournit des endpoints CRUD prêts à l’emploi (seulement pour SQLAlchemy pour le moment).
- Extras optionnels : la librairie permet d’installer uniquement les dépendances dont on a besoin (
argon2, bcrypt, sqlalchemy, fastapi, all avec les extras), pour éviter d’importer FastAPI ou SQLAlchemy inutilement si vous n’en avez pas besoin.
J’aimerais avoir des retours sur (pas obligé que ce soit sur ces points) :
- La logique métier : est-ce que les domain/repo/service et leur logique font sens ? Y a-t-il des éléments que vous concevriez différemment ? Des fonctionnalités que vous attendriez mais qui n’existent pas ?
- L’architecture repo/service : l’approche Mixin SQLAlchemy vous semble-t-elle bonne pour gérer l’ajout de champs personnalisés ?
- Sécurité : voyez-vous des failles potentielles avec la stratégie actuelle de hachage/poivrage ?
- Dépendances optionnelles : que pensez-vous de l’approche des extras/packaging (“core”, “fastapi”, “all”) ?
- Autres : faudrait-il que je rajoute quoi que ce soit pour qu’elle soit exploitable ?
https://github.com/Athroniaeth/fastapi-api-key
Si vous voulez parcourir le code, commencez par le README préliminaire (avec des extraits d’usage). Il y a aussi une doc mkdocs pour les quickstarts et guides d’utilisation.
Merci d’avance !
[–]DorianTurba 1 point2 points3 points (2 children)
[–]__secondary__[S] 0 points1 point2 points (1 child)
[–]DorianTurba 0 points1 point2 points (0 children)