Contactez-nous

Pas le temps de tout lire ?

Contactez-nous dès maintenant, et nous répondrons à vos besoins dans les plus brefs délais

Contactez-nous

Créer une API en .NET 6

Actualités
Le 25 avril 2022
par Romain D. & Matthieu F.
Attineos Applications

Cet article reprend dans les grandes lignes le précédent sur le .NET 5 tout en mettant à jour les subtilités de cette nouvelle version .NET 6

Introduction

Le .NET 6 ?

Le .NET 6, suite direct du .NET 5 monte rapidement ces derniers temps. Ceci n’est pas un hasard ! En effet, cette nouvelle mouture de Microsoft a toujours le même objectif : remplacer le .NET Framework historique. Contrairement à son aîné, cette technologie est OpenSource et a pour vocation de se rendre plus accessible à tous les systèmes d’exploitation. Un tournant dans la sphère Microsoft, qui a débuté avec le .NET CORE en 2016.

Pour ce début d’année 2022, que diriez-vous d’une petite veille technologique sur la dernière version de cet éco-système libre ? Et bien, c’est parti !

Au programme

Pour faire un tour d’horizon de cette technologie, je vais vous proposer une approche plutôt complète. Au dela de la création pure et simple d’une API, nous allons mettre en place tout ce qui gravite autour de ce type projet WEB. Voici la feuille de route que je vous propose :

  • Création d’une API en .NET 6
  • Mise en place d’une architecture simple mais posant les bases d’un découpage fonctionnel
  • Manipulation d’une base de données locale
  • Conception de la BDD par l’approche Entity Framework (Code First)
  • Sécurisation de l’API par Token JWT et rôles utilisateurs

Pré-requis

> Lorsque vous sélectionnez « Développement .NET Desktop« , n’hésitez pas à regarder si l’option « SQL Server Express LocalDB » est bien cochée dans la partie droite avant de lancer l’installation. > Installer l’IDE en anglais (Onglet « Modules linguistiques »), pour s’y retrouver parfaitement dans les captures qui vont suivre 😉

Création du projet API

Dans Visual Studio 2022, nous allons faire ce grand classique lors du lancement de l’IDE :

MbbQEqr

Ensuite, nous allons sélectionner « ASP.NET Core Web API » :

MR1nw28

Nommons maintenant le projet WEB, la solution et l’emplacement de tout cela :

LxXr7Dz

C’est maintenant que tout commence !

Ec0l2eE

> Faisons attentions à bien choisir :

  • la bonne version : .NET 6.0 (long-term support)

  • Et laissons les autres options par défaut

    🎉Félicitations 🎉 Votre API est créée :

    tt8mBZ0

> Le Template vous génère un contrôleur « WeatherForecastController » avec une méthode Get d’exemple déjà codée. Vous pouvez y jeter un oeil.

Cerise sur le gâteau, notre API est déjà fonctionnelle ! Pour le vérifier, lancer directement le projet après avoir pris soin de vérifier votre API est sélectionnée dans la partie débug (IIS Express peut être sélectionné par défaut) :

ytoRkCo

> ℹ IIS Express est un serveur WEB intégré à Visual Studio et permet le debug local de l’application

Après avoir lancer votre API, deuxième surprise !

Brgycik

> Swagger (générateur de documentation + testeur d’API), est déjà préinstallé !

Vous pouvez tester votre méthode de Get du Contrôleur WeatherForecast :

ETHGkwd

F9Vm6fh

> Pour plus d’informations sur Swagger, rendez-vous ici : https://docs.microsoft.com/fr-fr/aspnet/core/tutorials/web-api-help-pages-using-swagger?view=aspnetcore-6.0

Base de données locale

Une API qui répond avec des données fictives c’est bien, mais avoir une vraie base de données derrière c’est encore mieux ! Commençons par créer physiquement notre base !

Vérifier l’instance

Avec l’invite de commande, vérifions l’existence de l’instance LocalDB avec la commande bat sqllocaldb info 0aumVnJ

Vérifions qu’elle est démarrée avec : bat sqllocaldb info MSSQLLocalDB

> Pour aller plus loin :

  • Si l’instance n’est pas démarrée : sqllocaldb start MSSQLLocalDB
  • Si vous souhaitez créer votre instance : sqllocaldb create TineosLocalDB -s (« -s » pour la démarrer directement)
  • Si sqllocaldb n’est pas reconnu en tant que commande, il manque une option à l’installation de Visual Studio (voir plus haut dans la partie pré-requis)

Création de la BDD

Ouvrir SQL Server Managagement Studio (SSMS) et se connecter à la BDD ainsi :

42qtpEk

> Le préfixe « (localdb) » est obligatoire et invariable pour les bases locales comme la nôtre. > Ce qui suit correspond au nom de l’instance, dans notre cas « MSSQLLocalDB ».

Une fois connecté, on crée notre base de données TineosDatabase:

gBk68MN

WHExP8E

> Il n’y a maintenant plus rien à faire du côté de SSMS.

Modélisation de la BDD

Maintenant que notre base est créée physiquement, modélisons là sous Visual Studio avec l’aide d’Entity Framework. Afin de respecter un découpage fonctionnel, nous allons créer un projet dédié à notre base :

V6lpvI5

Celui-ci sera du type « Class Library » :

IgmkbgK

II7z5ON

Vérifions que la version de .NET est bien .NET 6

3A8iajE

nZcdEfi

> Class1.cs est à supprimer, sauf s’il est important pour vous de garder le 1er vestige de votre 1ère API .NET 6 pour des raisons sentimentales, libre à vous ! 😝).

Référençons Entity Framework dans nos projets. Pour cela nous allons utiliser le gestionnaire des packages NuGet :

3NU6C5i

> NuGet est un outil de gestion de bibliothèques intégré directement dans Visual Studio. Il nous évitera notamment de charger les DLL manuellement et gère aussi le versionning de celles-ci. Pour plus d’information sur le sujet, rendez-vous ici : https://docs.microsoft.com/fr-fr/nuget/consume-packages/install-use-packages-visual-studio

Installons-les packages suivants, dans leur dernière version, dans le projet Database uniquement :

  • Microsoft.AspNetCore.Identity.EntityFrameworkCore
  • Microsoft.EntityFrameworkCore
  • Microsoft.EntityFrameworkCore.SqlServer
  • Microsoft.EntityFrameworkCore.Tools

Installons le package suivant, dans sa dernière version, dans les deux projets :

  • Microsoft.EntityFrameworkCore.Design (le projet API, étant le point d’entrée de notre application, a besoin de cette référence pour générer notre base)

Créons notre tout premier Model Entity en ajoutant une nouvelle classe Tineos.cs dans le projet Database/EntityModels :

egKaFbO

> Cette classe servira à créer la table « Tineos »

Ajoutons maintenant quelques propriétés à notre classe et rendons la publique : « `cs public class Tineos { public int Id { get; set; }

public string FirstName { get; set; }

public string LastName { get; set; }

public string Mail { get; set; }

public string Password { get; set; }

public DateTime StartDate { get; set; }

public string JobFunction { get; set; }

}


> Ces propriétés deviendront les champs de la future table « Tineos » 
**Remarques** : 

* Par défault, Entity Framework reconnaitra automatiquement les propriétés « Id » ou « ID » ou encore « TineosId » comme la clé primaire de la future table.
* De plus si le type de cette propriété est int, une valeur incrémentale sera gérée automatiquement du côté de la base de données lors des ajouts.
Il est bien sûr possible de modifier ce comportement. Pour en savoir plus, rendez-vous ici : https://docs.microsoft.com/fr-fr/ef/core/modeling/generated-properties?tabs=data-annotations

Créons maintenant le contexte de notre base de données. Il s'agit du point d’entrée de nos données au niveau du code. Nous devons lister ici tous les modèles Entity que l’on souhaite rendre accessible par le biais du contexte.

Créons la classe `DatabaseContext.cs` à la racine du projet Database : 

![aCmMtvi](//images.ctfassets.net/5x495gb1i5mp/7KOvO0ZbsHCfeDyNL6KYTb/2b40b8ca7d3ed80601ab4a342a007f98/aCmMtvi.png)
cs public class DatabaseContext : DbContext

{ public DatabaseContext(DbContextOptions options) : base(options) {}

public DbSet Tineos {get; set;}

} « `

> * Notre classe doit étendre Microsoft.EntityFrameworkCore.DbContext, pour se raccrocher à Entity Framework. > * Il faut un constructeur permettant de passer des options au DbContext > * Et lister les collections des modèles par le biais de propriétés de type DbSet

Renseignons notre chaîne de connexion dans le Projet API, dans appsettings.Development.json :

"ConnectionStrings": {
        "TineosCnxStr": "Server=(localdb)\\MSSQLLocalDB;Initial Catalog=TineosDatabase;Integrated Security=true;MultipleActiveResultSets=True"
}

aY3t4rJ

> Remarque : appsettings.Development.json ne sera pris en compte uniquement dans le cas de notre machine local (ou toute autre machine où la variable d’environnement (VE) « ASPNETCORE_ENVIRONMENT » a pour valeur « Development ») Il est facile de jouer avec cette VE sur vos serveurs cibles pour variabiliser une chaîne de connexion, par exemple. Plus d’informations ici : https://docs.microsoft.com/fr-fr/aspnet/core/fundamentals/configuration/?view=aspnetcore-5.0

Pour que notre chaîne de connexion soit partagée dans toutes l’application, nous allons l’injecter par dépendance. Dans le Program.cs du projet API, ajouil suffit d’ajouter l’instruction suivante dans la méthode ConfigureServices() :

builder.Services.AddDbContext(
    options => options.UseSqlServer(builder.Configuration.GetConnectionString("TineosCnxStr")));

GbaJZos

> N’oubliez pas de référencer votre projet Database dans votre projet API afin de pouvoir référencer votre « DatabaseContext ». Cette configuration permettra d’injecter le contexte dans les classes voulues, en utilisant automatiquement la chaîne de connexion en paramètre du constructeur réalisé tout à l’heure.

Génération des tables

Les migrations

Pour générer les modèles présents dans notre contexte, il faut créer une migration. Ouvrir le Package Manager Console de Visual Studio :

KKBa6Gx

Sélectionner le projet Database par défaut :

GDnHio2

Lancer la commande suivante : Add-Migration InitialMigration > Un dossier migration a été créé dans notre projet DataBase avec dedans notre fichier de migration (nommé YYYYDDJJHHMMSS_InitialMigration.cs).

Pour mettre à jour la base, il faut lancer cette commande : Update-Database On peut observer sur SSMS que la base est à jour :

74PTHVX

> Pour chaque changement de modèles Entity (ajout, modification ou suppression), nous devons créer une nouvelle migration pour mettre à jour la base. Les scripts générés seront alors des différentiels par rapport à la dernière migration.

Ajouter des tables à notre BDD existante

Pour approfondir notre exemple, créons un nouveau modèle « Project » que nous allons lier à « Tineos » en many to many :

public class Project
{
        public int Id { get; set; }

        public string Name { get; set; }

        public DateTime StartDate { get; set; }

        public DateTime DeadLine { get; set; }

        public List ProjectTineos { get; set; }
}

Puis, l’entité d’association :

public class ProjectTineos
{
        public int TineosId { get; set; }

        public Tineos Tineos { get; set; }

        public int ProjectId { get; set; }

        public Project Project { get; set; }

}

Précisons qu’un Tineos peut avoir une liste de projets en ajoutant cette propriété dans la classe Tineos.cs :

public List TineosProject { get; set; }

Et complètons les propriétés DatabaseContext et ajoutons la méthode OnModelCreating() qui va préciser les clés primaires de la table d’association et on en profite pour ajouter quelques données pour les tests :

public class DatabaseContext : DbContext
{
    public DatabaseContext(DbContextOptions options) : base(options)
    {
    }

    public DbSet Tineos { get; set; }

    public DbSet Projects { get; set; }

    public DbSet ProjectTineos { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity()
                .HasKey(s => new { s.ProjectId, s.TineosId });

        var john = new Tineos { 
            Id = 1, 
            StartDate = DateTime.Now, 
            FirstName = "John", 
            LastName = "DOE", 
            Mail = "john.doe@mail.com", 
            Password = "password", 
            JobFunction = "Communication Expert" 
        };

        var jeny = new Tineos { 
            Id = 2, 
            StartDate = DateTime.Now, 
            FirstName = "Jeny", 
            LastName = "ANDERSON", 
            Mail = "jeny.anderson@mail.com", 
            Password = "password", 
            JobFunction = "Big Boss" 
        };

        var carl = new Tineos { 
            Id = 3, 
            StartDate = DateTime.Now, 
            FirstName = "Carl", 
            LastName = "WICK", 
            Mail = "carl.wick@mail.com", 
            Password = "password", 
            JobFunction = "Lead Developer" 
        };

        var google = new Project { Id = 1, StartDate = DateTime.Now, DeadLine = DateTime.Now.AddYears(100), Name = "Buy Google" };
        var piedPipper = new Project { Id = 2, StartDate = DateTime.Now, DeadLine = DateTime.Now.AddYears(2), Name = "Develop new Pied Pipper" };
        var happy = new Project { Id = 3, StartDate = DateTime.Now, DeadLine = DateTime.Now, Name = "Be Happy" };

        var assoGoogle1 = new ProjectTineos { ProjectId = google.Id, TineosId = john.Id };
        var assoGoogle2 = new ProjectTineos { ProjectId = google.Id, TineosId = jeny.Id };
        var assoPp = new ProjectTineos { ProjectId = piedPipper.Id, TineosId = carl.Id };
        var assoHappy1 = new ProjectTineos { ProjectId = happy.Id, TineosId = john.Id };
        var assoHappy2 = new ProjectTineos { ProjectId = happy.Id, TineosId = jeny.Id };
        var assoHappy3 = new ProjectTineos { ProjectId = happy.Id, TineosId = carl.Id };

        modelBuilder.Entity().HasData(john, jeny, carl);
        modelBuilder.Entity().HasData(google, happy, piedPipper);
        modelBuilder.Entity().HasData(assoHappy1, assoHappy2, assoHappy3, assoPp, assoGoogle1, assoGoogle2);

    }
}

> Ne créez pas au scandale tout de suite, les mots de passes en clair on va y revenir 👮‍♀️👮‍♂️

Créons une nouvelle migration (Add-Migration AddingProjects), mettons à jour la BDD (Update-Database) :

P3Lgw65

Requêter en base

Afin de continuer notre découpage fonctionnel, créons un nouveau projet Class Library « TineosProject.Domain » et y ajouter un dossier Models, Interfaces et Business :

m7vX5MR

Dans Models, créons une classe TineosModel :

public class TineosModel
{        
    public int Id { get; set; }

    public string FirstName { get; set; }

    public string LastName { get; set; }

    public string JobFunction { get; set; }

    public string Mail { get; set; }

    public DateTime StartDate { get; set; }

}

Dans /Interfaces, créons l’interface ITineosManager.cs et ITineosBusiness.cs comme ainsi :

vIptzGU

public interface ITineosManager
{
    List GetAllTineos();
}
public interface ITineosBusiness
{
    List GetAllTineos();
}

Dans /Business, créons TineosBusiness.cs :

public class TineosBusiness : ITineosBusiness
{
    public ITineosManager _tineosManager;

    public TineosBusiness(ITineosManager tineosManager)
    {
        _tineosManager = tineosManager;
    }

    public List GetAllTineos()
    {
        return _tineosManager.GetAllTineos();
    }
}

> L’instance du manager sera passée par injection de dépendance. Nous allons la configurer un peu plus bas.

Dans le projet TineosProject.Database, ajoutons la référence au projet TineosProject.Domain et ajoutons un dossier /Managers avec à l’intérieur la classe TineosManager.cs :

public class TineosManager : ITineosManager
{
    private readonly DatabaseContext _databaseContext;

    public TineosManager(DatabaseContext databaseContext)
    {
        _databaseContext = databaseContext;
    }

    public List GetAllTineos()
    {
        return _databaseContext.Tineos.Select(t => new TineosModel
        {
            Id = t.Id,
            FirstName = t.FirstName,
            LastName = t.LastName,
            JobFunction = t.JobFunction
        }).ToList();
    }
}

> Le contexte sera également passée par injection de dépendance (déjà configurée précédemment).

Direction le Program.cs du projet TineosProject.API, et ajouter la ligne suivante :

builder.Services.AddScoped();

CkUDM3q

Interrogeons notre API !

Dans notre projet API, créons un nouveau contrôleur Controller/TineosController.cs :

[ApiController]
[Route("[controller]")]
public class TineosController : ControllerBase
{
    private static ITineosBusiness _tineosBusiness;

    public TineosController(ITineosBusiness tineosBusiness)
    {
        _tineosBusiness = tineosBusiness;
    }

    [HttpGet]
    public ActionResult Get()
    {
        return Ok(_tineosBusiness.GetAllTineos());
    }
}

De la même manière, on configure l’injection de dépendance dans le Program.cs :

builder.Services.AddScoped();

faQxo8n

> Concernant l’injection de dépendance, il y a plusieurs cycles de vie possibles. Dans notre cas, nous utilisons « Scoped » afin que chaque requête HTTP utilise la même instance des objets passés en paramètre de constructeur. Il existe deux autres types : Transient (éphémère) et Singleton (pas besoin de l’expliquer celui-là, si ? 😋). Le choix se fait en fonction du rôle de ce que l’on souhaite injecter. Pour plus d’information sur le sujet, n’hésitez pas à lire cet article qui le résume déjà très bien : https://cdiese.fr/aspnet-core-dependency-injection/

On peut maintenant lancer le projet API et tester notre méthode Get() exposée :

zCwbYSC

Allons plus loin !

Dans le projet TineosProject.Domain, on ajoute une nouvelle signature dans l’interface ITineosBusiness.cs :

public interface ITineosBusiness
{
    List GetAllTineos();

    TineosModel AddTineos(AddTineosRequest request);
}

Avec un modèle de requête dans /Models/Requests/AddTineosRequest.cs :

public class AddTineosRequest
{
    [Required]
    public string FirstName { get; set; }

    [Required]
    public string LastName { get; set; }

    [Required]
    public DateTime StartDate { get; set; }

    [Required]
    public string JobFunction { get; set; }

    [Required]
    public string Mail { get; set; }

    [Required]
    public string Password { get; set; }
}

> Il est possible de spécifier dans le modèle d’entrée des champs obligatoires (entre-autres) par le biais des DataAnnotations (exemple : [Required] ). Ces annotations serviront notamment à valider les données d’entrée de notre méthode de contrôleur.

On continue notre chaîne dans ITineosManager.cs :

public interface ITineosManager
{
    List GetAllTineos();

    TineosModel AddTineos(TineosModel request , string clearPassword);
}

Et on implémente la méthode dans la classe TineosBusiness.cs :

public TineosModel AddTineos(AddTineosRequest request)
{
    var tineosToAdd = new TineosModel
    {
        FirstName = request.FirstName,
        LastName = request.LastName,
        JobFunction = request.JobFunction,
        Mail = request.Mail,
       StartDate = request.StartDate
    };
    return _tineosManager.AddTineos(tineosToAdd, request.Password);
}

> Remarques :

  • Ces méthodes sont pour l’instant des passe-plats dans la mesure où notre besoin est très simple. On pourrait imaginer qu’une méthode de la brique Business reçoit plusieurs paramètres et utilise plusieurs managers.
  • Les objets passés par le contrôleur vers le business sont les mêmes que ceux envoyés du domaine vers le manager. Nous gardons cette simplicité aujourd’hui pour alléger cet article, mais il convient en principe décorréler également ces deux couches.

Dans le projet TineosProject.Database, on implémente la nouvelle méthode dans TineosManager.cs :

public TineosModel AddTineos(TineosModel tineosModel, string clearPassword)
{
    var tineosToAdd = new Tineos
    {
        FirstName = tineosModel.FirstName,
        LastName = tineosModel.LastName,
        StartDate = DateTime.Now,
        JobFunction = tineosModel.JobFunction,
        Mail = tineosModel.Mail,
        Password = PasswordTool.HashPassword(clearPassword)
    };

    _databaseContext.Add(tineosToAdd);
    _databaseContext.SaveChanges();
    tineosModel.Id = tineosToAdd.Id;

    return tineosModel;
}

> Remarques :

  • Le mapping entre les objets pourrait être automatisé avec l’aide d’une librairie comme AutoMapper pour gagner en visibilité dans cette couche.
  • Allez, cette fois-ci on en parle ! NON : Nous n’allions pas stocker le mot de passe en clair quand même 😊 PasswordTool.HashPassword va nous aider à hacher le mot de passe avant insertion.

Voici un exemple de hachage créé dans un dossier /Tools du même projet :

public static class PasswordTool
{
    public static string HashPassword(string password)
    {
        byte[] salt = new byte[128 / 8];
        using (var rng = RandomNumberGenerator.Create())
        {
            rng.GetBytes(salt);
        }

        string hashed = Convert.ToBase64String(KeyDerivation.Pbkdf2(
            password: password,
            salt: Encoding.UTF8.GetBytes("saltForPasswordHashing"),
            prf: KeyDerivationPrf.HMACSHA512,
            iterationCount: 10000,
            numBytesRequested: 256 / 8));

        return hashed;
    }
}

> Penser à changer le salt et le variabiliser 😉 > Aussi, n’hésitez pas à revenir sur vos données « seedées » dans le fichier DatabaseContext.cs pour là aussi hacher les mots de passe placé en dur un peu plus haut :

var john = new Tineos
{
    Id = 1,
    StartDate = DateTime.Now,
    FirstName = "John",
    LastName = "DOE",
    Mail = "john.doe@mail.com",
    //Password = "password" --> #shame
    Password = PasswordTool.HashPassword("password"),
    JobFunction = "Communication Expert"
};

On peut maintenant implémenter notre nouvelle méthode de contrôleur pour ajouter un nouveau Tineos :

[HttpPost]
public ActionResult Post(AddTineosRequest request)
{
    if(ModelState.IsValid)
    {

        return Ok(_tineosBusiness.AddTineos(request));
    }
    else
    {
        return BadRequest(ModelState);
    }
}

> Un champ obligatoire non renseigné (le [Required] vu plus haut) aura pour conséquence d’invalider le test « ModelState.IsValid ». Dans notre cas, une BadRequest sera renvoyée avec le détail de l’erreur.

Testons la nouvelle méthode :

GeRuu0q

uX4EURr

On peut constater son ajout en base de données :

2nXktw3

Mise en place d’un token d’authentification JWT

Commençons par installer les packages suivants dans le projet TineosProject.API :

  • Microsoft.AspNetCore.Authentication
  • Microsoft.AspNetCore.Authentication.JwtBearer
  • Microsoft.IdentityModel.Tokens

Ensuite, créons une méthode de génération du Token JWT dans TineosProject.Domain/Tools/TokenTool.cs :

public static class TokenTool
{
    public static string GenerateJwt(TineosModel user, JwtSettings jwtSettings)
    {
        var claims = new List
        {
            new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()),
            new Claim(ClaimTypes.Name, $"{user.FirstName} {user.LastName}"),
            new Claim(ClaimTypes.Role, user.JobFunction)
        };

        var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(jwtSettings.Secret));
        var creds = new SigningCredentials(key, SecurityAlgorithms.HmacSha512);
        var expires = DateTime.Now.AddMinutes(Convert.ToDouble(jwtSettings.ExpirationInMinutes));

        var token = new JwtSecurityToken(
            issuer: jwtSettings.Issuer,
            audience: jwtSettings.Issuer,
            claims,
            expires: expires,
            signingCredentials: creds
        );
        return new JwtSecurityTokenHandler().WriteToken(token);
    }
}

Et créons ensuite la classe de configuration suivante /Models/Config/JwtSettings.cs :

public class JwtSettings
{
    public string Issuer { get; set; }
    public string Secret { get; set; }
    public int ExpirationInMinutes { get; set; }
}

> Ainsi que la configuration liée dans le appsettings.Development.json dans le projet TineosProject.API (nous ferons le lien un peu plus bas):

"JwtSettings": {
  "Issuer": "MyTineosAPI",
  "Secret": "JwtS3cr3tK3yWithM@ximumSiz3Is64Byt3s",
  "ExpirationInMinutes": 60
}

Dans Program.cs, configurons la partie JWT :

//configuration de l'authentification et du format de token
var jwtSettings = builder.Configuration.GetSection("JwtSettings").Get();

builder.Services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
    options.DefaultScheme = JwtBearerDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddJwtBearer(options =>
{
    options.RequireHttpsMetadata = false;
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidIssuer = jwtSettings.Issuer,
        ValidAudience = jwtSettings.Issuer,
        IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(jwtSettings.Secret)),
        ClockSkew = TimeSpan.Zero
    };
});

app.UseAuthentication();

Limitons maintenant l’utilisation de notre méthode POST en ajoutant l’attribut [Authorize] à celle-ci :

aYLpRTy

Testons maintenant l’accès à nos deux méthodes :

  • Pas de soucis pour la Méthode Get():

Rn5rHuf

  • On constate maintenant que notre méthode Post( ) est maintenant inaccessible :

V07W3nK

> Nous avons mis l’attribut [Authorize] aux dessus de notre méthode Post(), il est possible de mettre celui-ci directement au-dessus de la classe. Ainsi, le token sera demandé pour toutes les méthodes du contrôleur sauf mention spécifique contraire. > Il est possible d’avoir une stratégie générale et d’ensuite venir affiner au cas par cas avec d’autres attributs sur une méthode en particulier. Un attribut [AllowAnonymous] autorisera son appel sans token, malgré le fait que la classe ait l’attribut Authorize. Pour en savoir plus, rendez-vous ici : https://docs.microsoft.com/fr-fr/aspnet/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api

Création du Token

Créons une nouvelle signature et méthode dans ITineosManager.cs et TineosManager.cs qui va permettre de vérifier la validité des données de connexion :

public TineosModel AuthenticateTineos(string mail, string password)
{
    TineosModel result = null;
    var tineos =_databaseContext.Tineos.Where(t => t.Mail == mail).FirstOrDefault();

    if(tineos != null && tineos.Password == PasswordTool.HashPassword(password))
    {
        result = new TineosModel
        {
            Id = tineos.Id,
            FirstName = tineos.FirstName, 
            LastName = tineos.LastName,
            JobFunction = tineos.JobFunction,
            Mail = tineos.Mail,
            StartDate = tineos.StartDate
        };
    }
    return result;

}

Ajoutons maintenant une nouvelle interface IAuthBusiness.cs et une classe AuthBusiness.cs ainsi :

public interface IAuthBusiness
{
    TokenModel ConnectUser(ConnectUserRequest request);
}
public class AuthBusiness : IAuthBusiness
{
    public ITineosManager _tineosManager;
    private readonly IOptions _jwtSettings;

    public AuthBusiness(ITineosManager tineosManager, IOptions jwtSettings)
    {
        _tineosManager = tineosManager;
        _jwtSettings = jwtSettings;
    }

    public TokenModel ConnectUser(ConnectUserRequest request)
    {
        TokenModel result = null;
        var existingTineos = _tineosManager.AuthenticateTineos(request.Mail, request.Password);
        if (existingTineos != null)
        {
            result = new TokenModel
            {
                Mail = existingTineos.Mail,
                Token = TokenTool.GenerateJwt(existingTineos, _jwtSettings.Value)
            };
        }

        return result;
    }
}

Et les /Models/Requests/Auth/ConnectUserRequest.cs et /Models/TokenModel.cs correspondant :

public class ConnectUserRequest
{
    [Required]
    public string Mail { get; set; }

    [Required]
    public string Password { get; set; }
}
public class TokenModel
{
    public string Mail { get; set; }

    public string Token { get; set; }
}

ITineosManager est déjà injecté par dépendance, mais ce n’est pas le cas de JwtSettings. Pour cela il faut pas oublier cette instruction dans le Program.cs :

builder.Services.Configure(builder.Configuration.GetSection("JwtSettings"));

Et créons maintenant un nouveau contrôleur AuthController.cs :

[ApiController]
[Route("[controller]")]
public class AuthController : ControllerBase
{
    private static IAuthBusiness _authBusiness;

    public AuthController(IAuthBusiness authBusiness)
    {
        _authBusiness = authBusiness;
    }

    [HttpPost]
    public ActionResult Login(ConnectUserRequest request)
    {
        if (ModelState.IsValid)
        {
            var token = _authBusiness.ConnectUser(request);
            return token != null ? Ok(token) : BadRequest("Invalid credentials");
        }
        else
        {
            return BadRequest(ModelState);
        }
    }
}

Et toujours la même chanson, on oublie pas cette ligne dans le Program.cs pour injecter ITineosBusiness :

builder.Services.AddScoped();

Test de l’authentification

Configurons Swagger dans Program.cs pour qu’il puisse injecter un token JWT :

//configuration de Swagger
builder.Services.AddSwaggerGen(c =>
{
    c.SwaggerDoc("v1", new OpenApiInfo { Title = "TineosProject.API", Version = "v1" });

    c.AddSecurityDefinition("Bearer", new OpenApiSecurityScheme
    {
        Scheme = "Bearer",
        BearerFormat = "JWT",
        Description = "Ajouter le token ainsi : \"Bearer xxxx\" où xxxx est votre token d'authentification",
        Name = "Authorization",
        In = ParameterLocation.Header,
        Type = SecuritySchemeType.ApiKey,
    });

    c.AddSecurityRequirement(new OpenApiSecurityRequirement
    {
        {
                new OpenApiSecurityScheme
                {
                    Reference = new OpenApiReference
                    {
                        Type = ReferenceType.SecurityScheme,
                        Id = "Bearer"
                    }
                },
                new string[] {}
        }
    });
});

Testons maintenant la méthode d’authenfication de l’API avec un des comptes présents en base :

xyXnrqF

SCQtukD

Nous allons maintenant utiliser le token reçu pour s’authentifier. Pour cela cliquons sur le bouton Authorize en haut à droite de la page Swagger:

8uqe6Qj

et renseignons notre token fraichement obtenu (ne pas oublier de mettre « Bearer » devant) :

QJjHhSZ

Après avoir cliqué sur Authorize, vous pouvez-maintenant tester la méthode Tineos/Post que nous avons protégée tout à l’heure :

6HjjLl1

dVRZzgt

—

Affiner par rôle utilisateur

Il est aussi possible de limiter l’accès à une méthode à un rôle en particulier. Si vous avez été attentif tout à l’heure, vous avez remarqué que le rôle est stocké dans le token 🙄. Il est possible de limiter l’accès à un (ou plusieurs) rôle spécifique ainsi :

mRSBE4F

Si nous testons avec le même utilisateur (John Doe, qui a le rôle Communication Expert) que précédement la méthode /Tineos/Get, nous obtenons :

orRRShs

Si nous récupérons un token avec le tineos Jeny Anderson (dont le rôle est Big Boss), nous obtenons maintenant :

3WwKXRE

— ⚠ L’authentification proposée ici est simplifiée. En effet dans le cadre d’une application WEB, il convient de coupler un Token JWT avec un Refresh Token qui permet de maintenir une connexion. Sans quoi, dès que le Token JWT arrive à expiration, toutes les requêtes demandant une authentification seront non autorisées et provoqueront, fonctionnellement, une déconnexion de l’utilisateur (et si ce cas est bien géré 😁). Pour plus d’information sur le mécanisme d’un Resfresh Token, rendez-vous ici : https://jasonwatmore.com/post/2022/01/24/net-6-jwt-authentication-with-refresh-tokens-tutorial-with-example-api

—

Conclusion

Nous arrivons à la fin de cet article. Voici un résumé des notions que vous venez d’aborder :

  • Création d’une Web API en .NET 6 avec une ébauche d’architecture séparant les différentes couches fonctionnelles de notre application (API, Métier et BDD)
  • Création et manipulation d’une base de données locale avec l’approche Entity Code First et LocalDB
  • Manipulation de l’injection de dépendance native .NET 6
  • Sécurisation de l’API par Token JWT et par rôle

J’espère que cet article vous aura permis d’y voir un peu plus clair sur la création d’un projet API .NET 6 from scratch. Le but était de rester simple et de proposer un Getting Started. Les ajustements sont maintenant à votre main, en fonction de vos besoins et contraintes : c’est à vous de coder !

En comparaison au précedent article (https://www.attineos.com/blog/tech/mise-en-place-dune-api-en-net-5), le « gros » changement se résume à la suppression du fichier startup.cs et tout a été rassemblé dans le Program.cs qui est maintenant plus simple. En effet, il n’est plus sous forme d’une classe mais plutôt une liste d’instruction permettant de configurer son appli WEB. Microsoft a toutefois prévu une rétrocompatibilité pour le fichier startup.cs. Donc si vous souhaitez migrer vers .NET 6, le changement ne sera pas obligatoire, pour l’instant 🙂

Pour de plus amples informations sur .NET 6, rendez-vous ici : https://docs.microsoft.com/fr-fr/dotnet/fundamentals/

D’autres sujets intéressants