Wenn Sie eine Migration von Version 3.1 von .NET Core oder ASP.NET Core durchführen, können sich die in diesem Artikel aufgeführten Breaking Changes auf Ihre App auswirken.
ASP.NET Core
HTTP: Browser-SameSite-Änderungen mit Auswirkung auf die Authentifizierung
Bei einigen Browsern, z. B. Chrome und Firefox, gab es Breaking Changes bei deren Implementierungen von SameSite für Cookies. Die Änderungen wirken sich auf Remoteauthentifizierungsszenarien aus, z. B. OpenID Connect und WS-Verbund, die durch das Senden von SameSite=None deaktiviert werden müssen. SameSite=None funktioniert jedoch unter iOS 12 und einigen älteren Versionen anderer Browser nicht. Die App muss ermitteln, ob diese Versionen vorliegen, und SameSite weglassen.
SameSite ist eine Erweiterung des Normentwurfs von 2016 für HTTP-Cookies. Damit soll das Risiko einer websiteübergreifenden Anforderungsfälschung (Cross-Site Request Forgery, CSRF) minimiert werden. Es wurde ursprünglich als eine Funktion entwickelt, die die Server durch Hinzufügen der neuen Parameter aktivieren können. In ASP.NET Core 2.0 wurde die erstmalige Unterstützung für SameSite eingeführt.
Neues Verhalten
Google hat einen neuen Normentwurf vorgeschlagen, der nicht abwärtskompatibel ist. In der Norm wird der Standardmodus in Lax geändert und der neue Eintrag None zur Deaktivierung eingeführt. Lax ist für die meisten App-Cookies ausreichend, allerdings funktionieren standardübergreifende Szenarien wie die Anmeldung mit OpenID Connect und WS-Verbund dann nicht mehr. Die meisten OAuth-Anmeldungen sind aufgrund von Unterschieden beim Ablauf der Anforderung nicht betroffen. Der neue Parameter None führt zu Kompatibilitätsproblemen mit Clients, die den früheren Normentwurf implementiert haben (z. B. iOS 12). Chrome 80 enthält die Änderungen. Weitere Informationen finden Sie unter SameSite-Updates für den Chrome-Produkteinführungszeitplan.
ASP.NET Core 3.1 wurde aktualisiert, um das neue SameSite-Verhalten zu implementieren. Das Update definiert das Verhalten von SameSiteMode.None neu, um SameSite=None auszugeben, und ergänzt den neuen Wert SameSiteMode.Unspecified, um das SameSite-Attribut auszulassen. Der Standard für alle Cookie-APIs ist jetzt Unspecified, obwohl einige Komponenten, die Cookies verwenden, Werte festlegen, die sich eher auf die entsprechenden Szenarien beziehen, z. B. die OpenID Connect-Korrelation und Nonce-Cookies.
Änderungen bei Browsern und Spezifikationen, wie im vorangehenden Text erläutert.
Empfohlene Maßnahme
Apps, die mit Remotestandorten interagieren, z. B. über die Anmeldung über Drittanbieter, müssen folgende Aktionen ausführen:
Testen Sie diese Szenarien in mehreren Browsern.
Wenden Sie die Maßnahmen zur Ermittlung der Cookierichtlinien im Browser an, die in Unterstützung älterer Browser erläutert werden.
Informationen zu Tests und Browserermittlung finden Sie im folgenden Abschnitt.
Ermitteln, ob Sie betroffen sind
Testen Sie Ihre Web-App mit einer Clientversion, die das neue Verhalten aktivieren kann. Chrome, Firefox und Microsoft Edge Chromium verfügen über neue Featureflags, die für Tests verwendet werden können. Vergewissern Sie sich, dass Ihre App nach dem Anwenden der Patches mit älteren Clientversionen kompatibel ist, insbesondere mit Safari. Weitere Informationen finden Sie unter Unterstützung älterer Browser.
Chrome
Chrome 78 und höher liefert irreführende Testergebnisse. Diese Versionen verfügen über eine vorübergehende Entschärfung und akzeptieren Cookies, die weniger als zwei Minuten alt sind. Wenn die entsprechenden Testflags aktiviert sind, liefern Chrome 76 und 77 genauere Ergebnisse. Um das neue Verhalten zu testen, legen Sie chrome://flags/#same-site-by-default-cookies auf aktiviert fest. Bei Chrome 75 und früheren Versionen wurde ein Fehlschlagen mit der neuen None-Einstellung gemeldet. Weitere Informationen finden Sie unter Unterstützung älterer Browser.
Google stellt keine älteren Chrome-Versionen zur Verfügung. Sie können jedoch ältere Versionen von Chromium herunterladen, die für Tests ausreichen. Befolgen Sie die Anweisungen unter Herunterladen von Chromium.
In Safari 12 wurde der vorherige Entwurf streng implementiert, und der neue None-Wert in Cookies führt zu einem Fehler. Um dies zu vermeiden, muss der unter Unterstützung älterer Browser aufgeführte Code zur Browserermittlung verwendet werden. Sie müssen Tests mit Safari 12 und 13 sowie auf WebKit-Basis, Betriebssystemanmeldungen mit Microsoft Authentication Library (MSAL), Active Directory Authentication Library (ADAL) oder einer sonstigen von Ihnen verwendeten Bibliothek durchführen. Das Problem hängt von der zugrunde liegenden Betriebssystemversion ab. Bei OSX Mojave 10.14 und iOS 12 sind Kompatibilitätsprobleme mit dem neuen Verhalten bekannt. Das Problem lässt sich mit einem Upgrade auf OSX Catalina 10.15 bzw. iOS 13 beheben. Safari verfügt derzeit über kein Aktivierungsflag zum Testen des neuen Spezifikationsverhaltens.
Firefox
Die Firefox-Unterstützung für den neuen Standard kann in Version 68 und höher getestet werden, indem Sie sich auf der Seite about:config mit dem Featureflag network.cookie.sameSite.laxByDefaultanmelden. Bei älteren Versionen von Firefox sind keine Kompatibilitätsprobleme bekannt.
Microsoft Edge
Microsoft Edge unterstützt zwar den alten SameSite-Standard, ab Version 44 sind jedoch keine Kompatibilitätsprobleme mit dem neuen Standard aufgetreten.
Microsoft Edge Chromium
Das Featureflag ist edge://flags/#same-site-by-default-cookies. Bei Tests mit Microsoft Edge Chromium 78 wurden keine Kompatibilitätsprobleme festgestellt.
Electron
Zu den Electron-Versionen zählen ältere Versionen von Chromium. Beispielsweise ist die von Microsoft Teams verwendete Electron-Version Chromium 66, das das ältere Verhalten aufweist. Führen Sie Ihre eigenen Kompatibilitätstests mit der Version von Electron aus, die in Ihrem Produkt verwendet wird. Weitere Informationen finden Sie unter Unterstützung älterer Browser.
Unterstützung älterer Browser
Im SameSite-Standard von 2016 ist vorgeschrieben, dass unbekannte Werte als SameSite=Strict-Werte behandelt werden. Folglich kann es sein, dass bei älteren Browsern, die den ursprünglichen Standard unterstützen, Fehler auftreten, wenn eine SameSite-Eigenschaft mit dem Wert None erkannt wird. Web-Apps müssen eine Browserermittlung implementieren, wenn diese alten Browser unterstützt werden sollen. ASP.NET Core implementiert keine Browserermittlung für Sie, da die Werte des User-Agent-Anforderungsheaders sehr instabil sind und sich wöchentlich ändern. Stattdessen können Sie mithilfe eines Erweiterungspunkts in der Cookierichtlinie für User-Agentspezifische Logik hinzufügen.
Fügen Sie in Startup.cs folgenden Code hinzu:
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
}
Deaktivierungsschalter
Mit dem Kompatibilitätsschalter Microsoft.AspNetCore.SuppressSameSiteNone können Sie das neue ASP.NET Core-Cookieverhalten vorübergehend deaktivieren. Fügen Sie folgenden JSON-Code einer runtimeconfig.template.json-Datei in Ihrem Projekt hinzu:
Entwurfszeitbuilds geben nur allgemeine Paketverweise zurück
Ab .NET Core SDK 3.1.400 werden vom RunResolvePackageDependencies-Ziel nur Verweise auf Pakete der obersten Ebene zurückgegeben.
Eingeführt in Version
.NET Core SDK 3.1.400
Änderungsbeschreibung
In früheren Versionen des .NET Core SDK erstellte das RunResolvePackageDependencies-Ziel die folgenden MSBuild-Elemente, die Informationen aus der NuGet-Ressourcendatei enthielten:
PackageDefinitions
PackageDependencies
TargetDefinitions
FileDefinitions
FileDependencies
Mit diesen Daten füllt Visual Studio den Knoten „Abhängigkeiten“ im Projektmappen-Explorer auf. Es kann sich dabei jedoch um eine große Menge von Daten handeln, die nur benötigt werden, wenn der Knoten „Abhängigkeiten“ aufgeklappt wird.
Ab Version 3.1.400 des .NET Core SDK werden die meisten dieser Elemente nicht standardmäßig generiert. Nur Elemente vom Typ Package werden zurückgegeben. Wenn Visual Studio die Elemente zum Auffüllen des Knotens „Abhängigkeiten“ benötigt, liest Visual Studio die betreffenden Informationen direkt aus der Ressourcendatei.
Grund für die Änderung
Diese Änderung wurde eingeführt, um die Leistung beim Laden von Projektmappen in Visual Studio zu verbessern. Zuvor wurden alle Paketverweise geladen, darunter viele, die von den meisten Benutzern nie angezeigt wurden.
Empfohlene Maßnahme
Wenn Sie über eine MSBuild-Logik verfügen, die von der Erstellung dieser Elemente abhängt, legen Sie die Eigenschaft EmitLegacyAssetsFileItems in Ihrer Projektdatei auf true fest. Mit dieser Einstellung aktivieren Sie das vorherige Verhalten, bei dem alle Elemente erstellt werden.
Ab .NET Core 3.1 sind einige Windows Forms-Steuerelemente nicht mehr verfügbar.
Änderungsbeschreibung
Ab .NET Core 3.1 sind verschiedene Windows Forms-Steuerelemente nicht mehr verfügbar. Ersatzsteuerelemente, die ein besseres Design und eine umfassendere Unterstützung bieten, wurden in .NET Framework 2.0 eingeführt. Die veralteten Steuerelemente wurden zwar bereits aus den Designer-Toolboxen entfernt, konnten aber weiterhin verwendet werden.
Die folgenden Typen stehen nicht mehr länger zur Verfügung:
CellFormatting-Ereignis wird nicht ausgelöst, wenn QuickInfo angezeigt wird
Eine DataGridView zeigt nun Text- und die Fehler-QuickInfos einer Zelle an, wenn mit der Maus darauf gezeigt wird oder wenn sie mit der Tastatur ausgewählt wird. Wenn eine QuickInfo angezeigt wird, wird das DataGridView.CellFormatting-Ereignis nicht ausgelöst.
Änderungsbeschreibung
Vor .NET Core 3.1 wurde bei einer DataGridView, für die die ShowCellToolTips-Eigenschaft auf true festgelegt wurde, eine QuickInfo für den Text und Fehler einer Zelle angezeigt, wenn mit der Maus auf die Zelle gezeigt wurde. Es wurden keine QuickInfos angezeigt, wenn die Maus mit der Tastatur ausgewählt wurde (z. B. mit der TAB-TASTE, einer Tastenkombination oder den Pfeiltasten). Wenn der Benutzer eine Zelle bearbeitet hat und die DataGridView sich noch im Bearbeitungsmodus befunden hat und mit der Maus auf eine Zelle gezeigt wurde, für die die ToolTipText-Eigenschaft nicht festgelegt war, wurde ein CellFormatting-Ereignis ausgelöst, um den Text der Zelle für die Anzeige in der Zelle zu formatieren.
Um die Barrierefreiheitsstandards zu erfüllen, werden ab .NET Core 3.1 bei einer DataGridView, für die die ShowCellToolTips-Eigenschaft auf true festgelegt ist, QuickInfos für den Text und Fehler der Zelle nicht nur dann angezeigt, wenn mit der Maus darauf gezeigt wird, sondern auch, wenn sie mit der Tastatur ausgewählt wird. Infolge dieser Änderung wird das CellFormatting-Ereignis nicht ausgelöst, wenn mit der Maus auf Zellen gezeigt wird, für die ToolTipText-Eigenschaft nicht festgelegt ist, und die DataGridView sich im Bearbeitungsmodus befindet. Das Ereignis wird nicht ausgelöst, da der Inhalt der Zelle, auf die gezeigt wird, als QuickInfo und nicht in der Zelle dargestellt wird.
Eingeführt in Version
3.1
Empfohlene Aktion
Schreiben Sie Code um, der das CellFormatting-Ereignis benötigt, während sich die DataGridView im Bearbeitungsmodus befindet.
Die Quelle für diesen Inhalt finden Sie auf GitHub, wo Sie auch Issues und Pull Requests erstellen und überprüfen können. Weitere Informationen finden Sie in unserem Leitfaden für Mitwirkende.
Feedback zu .NET
.NET ist ein Open Source-Projekt. Wählen Sie einen Link aus, um Feedback zu geben:
Erstellen Sie eine Benutzeroberfläche mit Datenbindung. Ihre Benutzeroberfläche wird automatisch basierend auf den neuesten Daten aktualisiert. Die Daten werden wiederum als Reaktion auf Änderungen der Benutzeroberfläche aktualisiert.