Voyons ensemble comment paramétrer la gestion des droits avec asp.net core (mvc et razor page).
Nous allons découvrir ensemble la création du IdentityContext, la gestion des rôles, …
Paramétrage du context
Création d’un context normal, sans lien avec une gestion des droits.
Puis, définir le context comme gérant les droits
Notons ici le IdentityDbContext.
Il a déjà tous les DbSets dédiés pour la gestion des droits.
Puis, nous configurons le lien avec Identity
Notons ici que nous pouvons créer notre propre utilisateur. Il doit hériter alors de IdentityUser.
Utilisation du Scaffolder
Si aucun paramétrage existe de base, nous pouvons utiliser le scaffolder intégré à dotnet / vs
Choisissez Identité
Nous pouvons récupérer l’ensemble des pages pré-codées pour nous :
Et créer les classes pour le context et pour l’utilisateur
Cela permet aussi de préparer les middlewares pour :
- L’authentification
- L’autorisation
Différences entre authentification et autorisation :
Authentication vs. Authorization: What’s the Difference? | OneLogin
Authentication vs. Authorization
Authentication : vérifier que la personne que vous êtes est vraiment celle-ci
Autorisation : gestion des droits par rapport à un profil authentifié
C’est pourquoi nous avons :
Note: il faut rajouter cette ligne juste avant le app.run pour que tout fonctionne avec les fichiers auto-générés :
app.MapRazorPages();
Préparation et lancement de la migration
dotnet ef migrations add first-with-rights
Bien compiler avant de lancer la commande.
On peut obtenir l’erreur suivante
https://stackoverflow.com/questions/71011516/c-sharp-entity-framework-core-unable-to-resolve-service
https://bugs.mysql.com/bug.php?id=106592
L’idée ici c’est d’ajouter le paramétrage nécessaire pour le design time (ce qui est utilisé par le moteur de création des migrations)
Un dossier Migrations est apparu : Victoire !
Un snapshot vient d’être créé à côté de la première migration.
On peut alors mettre à jour la base de données :
dotnet ef database update
On peut tomber sur cette erreur :
Ne pas mettre (localhost) dans la partie Server. Bien préciser : 127.0.0.1
Les tables sont créées !
Étapes de paramétrage
Ajout d’un rôle
Mise à jour dans le program.cs
Ajout d’un rôle. Notons ici la possibilité de créer notre propre classe de rôle.
Ajout d’une règle par défaut pour toutes les pages
Ici, nous utilisons le builder dédié qui oblige à être authentifié pour toutes les pages.
Pour éviter une boucle infinie au démarrage et aussi permettre à tout le monde d’avoir un point de chute s’ils ne sont pas connectés :
Ça va surpasser les droits de sauvetage.
Seed de données pour le dev
On peut préparer des données à renseigner au démarrage de l’application, en dev par exemple.
Récupérer un context Scoped
Et pouvoir ainsi renseigner :
- les rôles par défaut
- les admins et users de base
Définition des rôles
Définition des users
Ajout de règles par Roles
Attention mettre un Authorize sur le controller supplante toute règle spécifique par action !
On peut spécifier une règle par Policy
Et l’utiliser après dans n’importe quel controller / action
Customiser la création des users (règles)
IdentityOptions permet de préciser plusieurs parties :
- Les règles sur le mot de passe
- Les règles pour le blocage de compte si mauvaise tentative
- Les règles pour le nommage de compte
- …
Règle d’authentication + cookie
Nous pouvons aussi définir les règles autour du cookie d’authentication (httponly ou non, …), les règles pour la redirection si non autorisé, …
Ca éveille votre curiosité ?! 🙂