Pour un exemple plus complet comprenant plus de fonctionnalités, voir le <a href="https://fastapi.tiangolo.com/fr/tutorial/">Tutoriel - Guide utilisateur</a>.

**Alerte spoiler** : le tutoriel - guide utilisateur inclut :

* Déclaration de **paramètres** provenant d'autres emplacements comme : **en-têtes**, **cookies**, **champs de formulaire** et **fichiers**.

Nous voulons obtenir `current_user` uniquement si cet utilisateur est actif.

Nous créons donc une dépendance supplémentaire `get_current_active_user` qui utilise à son tour `get_current_user` comme dépendance.

Ces deux dépendances renverront simplement une erreur HTTP si l'utilisateur n'existe pas, ou s'il est inactif.

Ainsi, dans notre endpoint, nous n'obtiendrons un utilisateur que si l'utilisateur existe, a été correctement authentifié et est actif :

Créez une fonction utilitaire pour hacher un mot de passe fourni par l'utilisateur.

Et une autre pour vérifier si un mot de passe reçu correspond au hachage stocké.

Et une autre pour authentifier et renvoyer un utilisateur.

{* ../../docs_src/security/tutorial004_an_py310.py hl[8,49,51,58:59,62:63,72:79] *}

Désormais, chaque fois qu'un navigateur crée un utilisateur avec un mot de passe, l'API renverra le même mot de passe dans la réponse.

Dans ce cas, cela peut ne pas poser de problème, car c'est le même utilisateur qui envoie le mot de passe.

Mais si nous utilisons le même modèle pour un autre *chemin d'accès*, nous pourrions envoyer les mots de passe de nos utilisateurs à tous les clients.

/// danger | Danger

Au lieu, par exemple, d’un `dict`, ou autre chose, ce qui pourrait casser l’application plus tard et constituer un risque de sécurité.

Nous vérifions également que nous avons un utilisateur avec ce nom d’utilisateur, et sinon, nous levons la même exception que précédemment.

{* ../../docs_src/security/tutorial005_an_py310.py hl[47,117:129] *}

## Vérifier les `scopes` { #verify-the-scopes }

* **Documenter** l'API avec OpenAPI :
    * ce qui est ensuite utilisé par les interfaces utilisateur de documentation interactive automatiques.

Tout cela peut sembler abstrait. Ne vous inquiétez pas. Vous verrez tout cela en action dans le [Tutoriel - Guide utilisateur](tutorial/index.md).

//// tab | Test

* vous
* votre

* p. ex.
* etc.

* `foo` en tant que `int`
* `bar` en tant que `str`
* `baz` en tant que `list`

* le Tutoriel - Guide utilisateur
* le Guide utilisateur avancé
* la documentation SQLModel
* la documentation de l’API
* la documentation automatique

* Data Science
* Apprentissage profond
* Apprentissage automatique
* Injection de dépendances

Vous pouvez utiliser la même technique pour étendre le JSON Schema et ajouter vos propres informations supplémentaires personnalisées.

Par exemple, vous pourriez l'utiliser pour ajouter des métadonnées pour une interface utilisateur frontend, etc.

///

/// info

OpenAPI 3.1.0 (utilisé depuis FastAPI 0.99.0) a ajouté la prise en charge de `examples`, qui fait partie du standard **JSON Schema**.

Il existait déjà une interface utilisateur Web pour les API Swagger. Donc, être capable de générer une documentation
Swagger pour une API permettrait d'utiliser cette interface utilisateur web automatiquement.

À un moment donné, Swagger a été cédé à la Fondation Linux, puis a été rebaptisé OpenAPI.

Par exemple `/users/me`, disons pour récupérer les données de l'utilisateur actuel.

Et vous pouvez aussi avoir un chemin `/users/{user_id}` pour récupérer des données sur un utilisateur spécifique grâce à un identifiant d'utilisateur.