Partager via

Changements cassants dans .NET 3.1

  • Article

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.

Pour plus d’informations sur ce problème, consultez dotnet/aspnetcore#14996.

Version introduite

3.1 Préversion 1

Ancien comportement

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 d’autres changements récents dans cette zone, consultez HTTP : Certaines valeurs par défaut du cookie SameSite ont été remplacées par Aucune. Dans ASP.NET Core 3.0, la plupart des valeurs par défaut sont passées de SameSiteMode.Lax à SameSiteMode.None (mais elles utilisent toujours la norme précédente).

Raison du changement

Le navigateur et la spécification changent comme indiqué dans le texte précédent.

Les applications qui interagissent avec des sites distants, par le biais d’une connexion tierce, par exemple, doivent :

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

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 :

{
  "configProperties": {
    "Microsoft.AspNetCore.SuppressSameSiteNone": "true"
  }
}
Autres versions

Les patches SameSite connexes sont à venir pour :

  • ASP.NET Core 2.1, 2.2 et 3.0
  • Microsoft.Owin 4.1
  • System.Web (pour .NET Framework 4.7.2 et versions ultérieures)

Category

ASP.NET

API affectées

Déploiement

Chemin d’accès d’ordinateur hôte x86 sur Windows 64 bits

MSBuild

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.

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.

Category

MSBuild

API affectées

N/A

SDK

Manifestes de l’outil dans le dossier racine

Windows Forms

Contrôles supprimé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.

Les types suivants ne sont plus disponibles :

Version introduite

3.1

Chaque contrôle supprimé correspond à un contrôle de remplacement recommandé. Reportez-vous au tableau suivant :

Suppression du contrôle (API) Remplacement recommandé API associées supprimées
ContextMenu ContextMenuStrip
DataGrid DataGridView DataGridCell, DataGridRow, DataGridTableCollection, DataGridColumnCollection, DataGridTableStyle, DataGridColumnStyle, DataGridLineStyle, DataGridParentRowsLabel, DataGridParentRowsLabelStyle, DataGridBoolColumn, DataGridTextBox, GridColumnStylesCollection, GridTableStylesCollection, HitTestType
MainMenu MenuStrip
Menu ToolStripDropDown, ToolStripDropDownMenu MenuItemCollection
MenuItem ToolStripMenuItem
ToolBar ToolStrip ToolBarAppearance
ToolBarButton ToolStripButton ToolBarButtonClickEventArgs, ToolBarButtonClickEventHandler, ToolBarButtonStyle, ToolBarTextAlign

Category

Windows Forms

API affectées

É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

Refactorisez tout code qui dépend de l’événement CellFormatting alors que DataGridView est en mode édition.

Category

Windows Forms

API affectées

None

Voir aussi