Configurer l’accès pour les fournisseurs et les rôles
Avec l’authentification utilisateur en place, votre application web de liste d’achats a besoin d’un moyen pour limiter l’accès à certaines pages aux utilisateurs qui ne sont pas connectés et pour autoriser la connexion uniquement via des fournisseurs spécifiques.
Nous examinerons la configuration et les rôles de routage dans Azure Static Web Apps pour optimiser l’accès utilisateur à notre application web.
Fichier de configuration pour Azure Static Web Apps
La configuration d’Azure Static Web Apps est définie dans le fichier staticwebapp.config.json
, qui contrôle les paramètres suivants :
- Routage
- Authentification
- Autorisation
- Règles de secours
- Remplacement des réponses HTTP
- Définitions globales d’en-tête HTTP
- Types MIME personnalisés
L’emplacement recommandé pour le staticwebapp.config.json
se trouve dans le dossier défini par le paramètre app_location
que nous avons choisi pendant le déploiement. Toutefois, le fichier peut être placé à n’importe quel emplacement au sein du dossier du code source de votre application.
Pour notre cas d’utilisation, nous examinerons la configuration du routage pour obtenir ce que nous voulons.
Restreindre les fournisseurs d’authentification
Dans une section précédente, nous avons vu que, par défaut, tous les fournisseurs d’authentification sont activés. Nous pouvons modifier cela en ajoutant des règles de routage à la configuration.
Par exemple, pour désactiver la connexion via le fournisseur GitHub, vous pouvez ajouter une règle d’acheminement comme celle-ci dans le fichier staticwebapp.config.json
.
{
"routes": [
{
"route": "/.auth/login/github",
"statusCode": 404
}
]
}
Nous forçons la route /.auth/login/github
utilisée pour l’authentification auprès du fournisseur GitHub à retourner une erreur 404
(Introuvable) afin que les utilisateurs ne puissent pas y accéder. Vous pouvez ajouter autant de règles d’itinéraires que vous souhaitez pour désactiver tous les fournisseurs que vous ne souhaitez pas utiliser.
Sécuriser les routes avec des rôles
Les itinéraires sont accessibles par défaut à tout le monde sans aucune restriction. Vous pouvez lsécuriser les itinéraires en y ajoutant un ou plusieurs noms de rôles dans le tableau allowedRoles
de la règle. Par défaut, chaque utilisateur appartient au rôle anonymous
intégré et tous les utilisateurs connectés sont membres du rôle authenticated
.
Par exemple, pour limiter un itinéraire aux seuls utilisateurs authentifiés, ajoutez le rôle authenticated
intégré au tableau allowedRoles
.
{
"routes": [
{
"route": "/profile",
"allowedRoles": ["authenticated"]
}
]
}
Avec cette configuration, si un utilisateur non authentifié tente d’accéder à l'itinéraire /profile
, une erreur 401
(non autorisée) est retournée.
Vous pouvez également restreindre des méthodes HTTP spécifiques pour une route donnée, comme suit :
{
"routes": [
{
"route": "/profile",
"methods": ["PUT", "POST", "DELETE"],
"allowedRoles": ["authenticated"]
}
]
}
Dans cet exemple, tous les utilisateurs peuvent accéder à la méthode GET
sur l'itinéraire /profile
, mais seuls les utilisateurs authentifiés peuvent utiliser PUT
, POST
ou DELETE
.
Utiliser un caractère générique
Vous pouvez utiliser un caractère générique à la fin de l’itinéraire pour faire correspondre tous les itinéraires suivant le modèle de base. Par exemple, pour restreindre toutes les URL commençant par /api
pour les utilisateurs authentifiés, vous pouvez écrire :
{
"routes": [
{
"route": "/api/*",
"allowedRoles": ["authenticated"]
}
]
}
Étapes suivantes
Nous allons ensuite implémenter des restrictions d’accès dans notre application.