Si vous effectuez une migration vers la version 3.1 de .NET Core ou d’ASP.NET Core, les changements cassants répertoriés dans cet article peuvent affecter votre application.
ASP.NET Core
HTTP : impact des changements apportés à la propriété SameSite du navigateur sur l’authentification
Certains navigateurs, tels que Chrome et Firefox, ont apporté des changements cassants à leurs implémentations de SameSite dans le cadre de la gestion des cookies. Les changements ont un impact sur les scénarios d’authentification à distance, tels que OpenID Connect et WS-Federation, qui doivent les refuser en envoyant SameSite=None. Toutefois, SameSite=None s’arrête sur iOS 12 et certaines versions antérieures d’autres navigateurs. L’application doit détecter ces versions et omettre SameSite.
SameSite est une extension du projet de norme 2016 pour les cookies HTTP. Cela permet d’atténuer la falsification de requête intersites (CSRF, Cross Site Request Forgery). À l’origine, il s’agissait d’une fonction à laquelle les serveurs devaient adhérer en ajoutant les nouveaux paramètres. SameSite est pris en charge à partir d’ASP.NET Core 2.0.
Nouveau comportement
Google a proposé une nouveau projet de norme qui n’est pas rétrocompatible. La norme modifie le mode par défaut sur Lax et ajoute une nouvelle entrée None pour refuser. Lax suffit pour la plupart des cookies d’application. Toutefois, il arrête les scénarios intersites comme OpenID Connect et la connexion WS-Federation. La plupart des connexions OAuth ne sont pas affectées en raison de différences de traitement des flux de requêtes. Le nouveau paramètre None provoque des problèmes de compatibilité avec les clients qui ont implémenté le projet de norme précédent (par exemple, iOS 12). Les changements seront inclus dans Chrome 80. Consultez les mises à jour de SameSite dans le cadre de la chronologie des lancements de produits Chrome.
ASP.NET Core 3.1 a été mis à jour pour implémenter le nouveau comportement SameSite. La mise à jour redéfinit le comportement de SameSiteMode.None afin d’émettre SameSite=None et ajoute une nouvelle valeur, SameSiteMode.Unspecified, afin d’omettre l’attribut SameSite. Toutes les API de cookie sont désormais définies par défaut sur Unspecified bien que certains composants qui utilisent des cookies définissent des valeurs plus spécifiques à leurs scénarios tels que la corrélation OpenID Connect et les cookies nonce.
Pour obtenir des instructions de test et de détection de navigateur, consultez la section suivante.
Déterminer si vous êtes affecté
Tester votre application web à l’aide d’une version cliente qui peut opter pour le nouveau comportement. Chrome, Firefox et Microsoft Edge Chromium ont tous de nouveaux indicateurs de fonctionnalité d’acceptation qui peuvent être utilisés pour les tests. Vérifiez que votre application est compatible avec les versions antérieures du client après avoir appliqué les patches, en particulier Safari. Pour plus d’informations, consultez Prendre en charge les navigateurs plus anciens.
Chrome
Chrome 78 et les versions ultérieures produisent des résultats de test trompeurs. Ces versions ont mis en place une mesure d’atténuation temporaire et autorisent les cookies de moins de deux minutes. Avec les indicateurs de test appropriés activés, Chrome 76 et 77 donnent des résultats plus précis. Pour tester le nouveau comportement, activez chrome://flags/#same-site-by-default-cookies sur activé. Chrome 75 et versions antérieures échouent avec le nouveau paramètre None. Pour plus d’informations, consultez Prendre en charge les navigateurs plus anciens.
Google ne met pas à disposition les anciennes versions de Chrome. Toutefois, vous pouvez télécharger des versions antérieures de Chromium, ce qui suffit pour les tests. Suivez les instructions sur Télécharger Chromium.
Safari 12 a strictement implémenté le brouillon précédent et échoue s’il rencontre la nouvelle valeur None dans les cookies. Cela doit être évité via le code de détection du navigateur indiqué dans Prendre en charge les navigateurs plus anciens. Veillez à tester Safari 12 et 13, ainsi que les connexions de type système d’exploitation basées sur WebKit à l’aide de Microsoft Authentication Library (MSAL), d’Active Directory Authentication Library (ADAL) ou de toute autre bibliothèque que vous utilisez. Le problème dépend de la version sous-jacente du système d’exploitation. OSX Mojave 10.14 et iOS 12 sont connus pour avoir des problèmes de compatibilité avec le nouveau comportement. La mise à niveau vers OSX Catalina 10.15 ou iOS 13 résout le problème. Safari n’a actuellement pas d’indicateur d’adhésion pour tester le nouveau comportement de spécification.
Firefox
La prise en charge de Firefox pour la nouvelle norme peut être testée sur la version 68 et ultérieure en acceptant sur la page about:config avec l’indicateur de fonctionnalité network.cookie.sameSite.laxByDefault. Aucun problème de compatibilité n’a été signalé sur les versions antérieures de Firefox.
Microsoft Edge
Bien que Microsoft Edge prenne en charge l’ancienne norme SameSite, à partir de la version 44, il n’a pas rencontré de problèmes de compatibilité avec la nouvelle norme.
Microsoft Edge Chromium
L’indicateur de fonctionnalité est edge://flags/#same-site-by-default-cookies. Aucun problème de compatibilité n’a été observé lors du test avec Microsoft Edge Chromium 78.
Electron
Les versions d’Electron incluent des versions antérieures de Chromium. Par exemple, la version d’Electron utilisée par Microsoft Teams est Chromium 66, qui présente l’ancien comportement. Effectuez vos propres tests de compatibilité avec la version d’Electron utilisée par votre produit. Pour plus d’informations, consultez Prendre en charge les navigateurs plus anciens.
Prendre en charge des navigateurs plus anciens
La norme SameSite 2016 exigeait que les valeurs inconnues soient traitées comme des valeurs SameSite=Strict. Par conséquent, tous les navigateurs plus anciens qui prennent en charge la norme d’origine peuvent s’arrêter lorsqu’ils rencontrent une propriété SameSite ayant la valeur None. Les applications web doivent implémenter la détection de navigateur si elles doivent prendre en charge ces anciens navigateurs. ASP.NET Core n’implémente pas la détection de navigateur pour vous, car les valeurs d’en-tête de demande User-Agent sont hautement instables et modifiées chaque semaine. Au lieu de cela, un point d’extension dans la stratégie de cookie vous permet d’ajouter une logique propre à User-Agent.
Dans Startup.cs, ajoutez le code suivant :
private void CheckSameSite(HttpContext httpContext, CookieOptions options)
{
if (options.SameSite == SameSiteMode.None)
{
var userAgent = httpContext.Request.Headers["User-Agent"].ToString();
// TODO: Use your User Agent library of choice here.
if (/* UserAgent doesn't support new behavior */)
{
options.SameSite = SameSiteMode.Unspecified;
}
}
}
public void ConfigureServices(IServiceCollection services)
{
services.Configure<CookiePolicyOptions>(options =>
{
options.MinimumSameSitePolicy = SameSiteMode.Unspecified;
options.OnAppendCookie = cookieContext =>
CheckSameSite(cookieContext.Context, cookieContext.CookieOptions);
options.OnDeleteCookie = cookieContext =>
CheckSameSite(cookieContext.Context, cookieContext.CookieOptions);
});
}
public void Configure(IApplicationBuilder app)
{
// Before UseAuthentication or anything else that writes cookies.
app.UseCookiePolicy();
app.UseAuthentication();
// code omitted for brevity
}
Commutateurs de refus
Le commutateur de compatibilité Microsoft.AspNetCore.SuppressSameSiteNone vous permet de désactiver temporairement le nouveau comportement de cookie ASP.NET Core. Ajoutez le code JSON suivant à un fichier runtimeconfig.template.json dans votre projet :
Les builds design-time retournent uniquement les références de package de niveau supérieur
À compter du Kit de développement logiciel (SDK) .NET Core 3.1.400, seules les références de package de niveau supérieur sont retournées par la cible RunResolvePackageDependencies.
Version introduite
SDK .NET Core 3.1.400
Description de la modification
Dans les versions précédentes du Kit de développement logiciel (SDK) .NET Core, la cible RunResolvePackageDependencies créait les éléments MSBuild suivants qui contenaient des informations du fichier de ressources NuGet :
PackageDefinitions
PackageDependencies
TargetDefinitions
FileDefinitions
FileDependencies
Ces données sont utilisées par Visual Studio pour remplir le nœud Dépendances dans l’Explorateur de solutions. Toutefois, il peut s’agir d’une grande quantité de données et les données ne sont pas nécessaires, sauf si le nœud Dépendances est développé.
À compter du Kit de développement logiciel (SDK) .NET Core version 3.1.400, la plupart de ces éléments ne sont pas générés par défaut. Seuls les éléments de type Package sont retournés. Si Visual Studio a besoin des éléments pour remplir le nœud Dépendances, il lit les informations directement à partir du fichier de ressources.
Raison du changement
Cette modification a été introduite pour améliorer les performances de chargement de solution à l’intérieur de Visual Studio. Auparavant, toutes les références de package étaient chargées, ce qui impliquait le chargement de nombreuses références que la plupart des utilisateurs n’afficheraient jamais.
Action recommandée
Si vous avez une logique MSBuild qui dépend de ces éléments créés, définissez la propriété EmitLegacyAssetsFileItems sur true dans votre fichier projet. Ce paramètre active le comportement précédent dans lequel tous les éléments sont créés.
À compter de .NET Core 3.1, certains contrôles Windows Forms ne sont plus disponibles.
Description de la modification
À compter de .NET Core 3.1, plusieurs contrôles Windows Forms ne sont plus disponibles. Des contrôles de remplacement qui présentent une meilleure conception et une meilleure prise en charge ont été introduits dans .NET Framework 2.0. Les contrôles déconseillés ont été supprimés auparavant des boîtes à outils du concepteur, mais il était toujours possible de les utiliser.
Événement CellFormatting non déclenché si l’info-bulle est affichée
DataGridView affiche désormais le texte et les info-bulles d’erreur quand l’utilisateur place le curseur sur une cellule ou et lorsqu’elle est sélectionnée via le clavier. Si une info-bulle est affichée, l’événement DataGridView.CellFormatting n’est pas déclenché.
Description de la modification
Avant .NET Core 3.1, une DataGridView dont la propriété ShowCellToolTips était définie sur true affichait une info-bulle pour le texte et les erreurs d’une cellule quand l’utilisateur plaçait le curseur dessus. Les info-bulles ne s’affichaient pas quand une cellule était sélectionnée via le clavier (par exemple à l’aide de la touche de tabulation, de touches de raccourci ou de la navigation avec les flèches). Si l’utilisateur a modifié une cellule, puis, alors que DataGridView était encore en mode d’édition, placé le curseur sur une cellule dont la propriété ToolTipText n’était pas définie, un événement CellFormatting a été déclenché pour mettre en forme le texte de la cellule pour l’affichage dans la cellule.
Pour répondre aux normes d’accessibilité, à compter de .NET Core 3.1, une DataGridView dont la propriété ShowCellToolTips est définie sur true affiche les info-bulles pour le texte et les erreurs d’une cellule non seulement quand l’utilisateur place le curseur sur une cellule, mais également lorsqu’elle est sélectionnée via le clavier. En raison de cette modification, l’événement CellFormatting n’est pas déclenché quand l’utilisateur place le curseur sur les cellules dont la propriété ToolTipText n’est pas définie alors que DataGridView est en mode d’édition. L’événement n’est pas déclenché, car l’utilisateur place le curseur sur une cellule dont le contenu est affiché sous la forme d’une info-bulle au lieu d’être affiché dans la cellule.
Version introduite
3.1
Action recommandée
Refactorisez tout code qui dépend de l’événement CellFormatting alors que DataGridView est en mode édition.
La source de ce contenu se trouve sur GitHub, où vous pouvez également créer et examiner les problèmes et les demandes de tirage. Pour plus d’informations, consultez notre guide du contributeur.
Commentaires sur .NET
.NET est un projet open source. Sélectionnez un lien pour fournir des commentaires :
Créer une interface utilisateur avec la liaison de données. Votre interface utilisateur est automatiquement mise à jour en fonction des données les plus récentes, tandis que les données sont mises à jour suite aux modifications apportées à l’interface utilisateur.