Par défaut, il n’est pas autorisé de faire des requêtes entre une application qui est dans un domaine A vers une autre qui serait dans un domaine B (pour des raisons de sécurité, il y a plus de détails dans les sources).
Si vous avez un front qui tourne sur un serveur node localhost:4200 et votre backend .Net sur localhost:7248), les requêtes du front vers le back seront bloquées car ils sont dans des domaines différents (ils n’ont pas le même numéro de port).
Si vous n’autorisez pas les CORS dans votre application, vous aurez un message de ce type:
Response body is not available to scripts (Reason: CORS Missing Allow Origin)
Autoriser les CORS dans votre application .NET
Techniquement, lorsque votre front va appeler votre backend .NET, il va avant tout faire un appel de type OPTION qu’on appelle le “preflight check”. En réponse, votre backend va indiquer quels autres domaines peuvent le solliciter et sur quelles routes.
On va simplement aller dans le fichierProgram.cs et définir une politique d’autorisation via le code suivant:
Il faut ensuite appliquer cette politique en rajoutant dans votre fichier:
app.UseCors(myAllowSpecificOrigins);
Faites très attention à l’endroit où vous mettez cette ligne de code, elle doit suivre l’ordre de déclaration préconisé par .NET donc avant app.UseAuthentication() ou app.UseResponseCaching() si vous les utilisez. Voici l’ordre préconisé par .NET à l’heure actuelle pour être sûr de ne pas vous tromper !
using Microsoft.AspNetCore.Identity;
using Microsoft.EntityFrameworkCore;
using WebMiddleware.Data;
var builder = WebApplication.CreateBuilder(args);
var connectionString = builder.Configuration.GetConnectionString("DefaultConnection")
?? throw new InvalidOperationException("Connection string 'DefaultConnection' not found.");
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(connectionString));
builder.Services.AddDatabaseDeveloperPageExceptionFilter();
builder.Services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
.AddEntityFrameworkStores<ApplicationDbContext>();
builder.Services.AddRazorPages();
builder.Services.AddControllersWithViews();
var app = builder.Build();
if (app.Environment.IsDevelopment())
{
app.UseMigrationsEndPoint();
}
else
{
app.UseExceptionHandler("/Error");
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
// app.UseCookiePolicy();
app.UseRouting();
// app.UseRateLimiter();
// app.UseRequestLocalization();
// app.UseCors();
app.UseAuthentication();
app.UseAuthorization();
// app.UseSession();
// app.UseResponseCompression();
// app.UseResponseCaching();
app.MapRazorPages();
app.MapDefaultControllerRoute();
app.Run();
Si vous avez bien appliqué cette méthode vous ne devriez plus avoir d’erreur 🙂En regardant le preflight check dans le navigateur (la requête de type OPTION) dans l’onglet réseau, on voit bien qu’on a notre backend répond l’url supportée, avec la méthode et le header approprié (premier rectangle rouge sur la capture d’écran) et ça doit matcher avec les headers de la requête envoyée (2 autres rectangles).
Conseil: Si ça ne fonctionne pas, pensez bien à comparer les URL définies dans le header de la requête et de la réponse, on peut se faire avoir par un petit “/” à la fin d’une des deux url 😛
Conclusion
J’espère que vous avez toutes les clefs pour gérer correctement les CORS dans votre application .NET. Pour aller plus loin, n’hésitez pas à regarder nos sources 🙂
Il arrive souvent que pour tester unitairement des règles de validation, on doive tester le même cas mais avec des exemples différents. Sans tests paramétrés, ça revient à faire un test par cas ce qui peut alourdir notre fichier de tests.
On va voir comment simplifier tout ça avec des tests paramétrés.
Prenons l’exemple d’une classe “Nom de Royaume” où je veux m’assurer ...
Avant .Net 8, tester du code qui utilise DateTime.Now() n’était pas trivial, on devait faire en sorte de mocker la Clock dans nos tests. Depuis .Net 8, c’est beaucoup plus facile grâce à TimeProvider inclut par défaut !
En deux mots, TimeProvider est une...
La gestion des erreurs de son API est très importante pour que les consommateurs puissent avoir une description claire du problème mais c’est souvent fastidieux à maintenir.
On va voir comment avoir des statuts de réponse cohérent et des messages d’erre...
On va voir comment avoir en quelques minutes des assertions qui vont vérifier les endpoints de notre API avec des scénarios de ce genre:
Feature: Create a new account
As a visitor,
I can create an account to access the game
Scenario: A visitor c...