Wir haben aktuell eine Eigenentwicklung in Planung, die auf C# ASP.NET Core und Blazor aufsetzt.

Im Zuge dieser Entwicklung haben wir natürlich auch die über das Framework bereitgestellte Methodik ein Login implementiert. Was natürlich nicht ausbleibt: .Net wird ab und an aktualisiert und just nach entsprechenden Aktualisierungen wollte zunächst nichts mehr.

Dabei gab es verschiedene Probleme: Zuerst wollte der Login nicht mehr so recht. Es konnte zwar noch ein erfolgreicher Login erzeugt werden und im Konsolenlog kam auch die Meldung „User logged in“ aber in den Nachfolgenden Bereichen – dort wo dann Daten basierend auf dem aktuellen User abgerufen werden sollten, kam der Fehler, dass keine „Authenticated user“ vorhanden wäre. Nanu?

Abgesehen davon, dass verschiedenes Zurücksetzen der verwendeten Nuget-Pakete etc. erst mal dafür sorgten, dass in der verwendeten Visual Studio 2022 Preview Version das Projekt gar nicht mehr wollte, stellte sich die Lösung dann als vergleichsweise einfach dar. Aber der Reihe nach.

Das „zerschossene“ Projekt ließ sich auffangen, indem die Visual Studio 2022 (ohne Preview) Version installiert und damit das Projekt geöffnet wurde. Die Preview-Version ist jetzt in diesem Szenario auch obsolet. Wir hatten sie installiert zu einem Zeitpunkt, als Maui und auch Blazor sowie das „.Net 8“ gerade erst ins Visual Studio gewandert waren und wir aber damit schon entwickeln wollten.

Trotzdem blieb dann der merkwürdige Fehler: Seite aufgerufen, die ein Login erfordert -> Weiterleitung zum Login -> Erfolgreicher Login -> Rückkehr auf ursprüngliche Seite -> User nicht authenticated = Keine Daten.

Was war das Problem?

Die Applikation ist eine sogenannte hybride Blazor-App. Das heißt, es gibt sowohl eine serverseitige Anwendung als auch einen clientseitigen Teil. Beide Seiten müssen – damit das mit dem authenticated user klappt – den passenden AuthenticationStateProvider implementieren. Beide hatten dies auch.

Allerdings hatte sich offenbar bei dem ganzen Update-Wirrwarr und „wieder zum Laufen bekommen wollen“ unbemerkt der eine Scope von

builder.Services.AddScoped<AuthenticationStateProvider, PersistingRevalidatingAuthenticationStateProvider>();

auf

builder.Services.AddScoped<AuthenticationStateProvider, IdentityRevalidatingAuthenticationStateProvider>();

gestellt.

Offenbar vertragen sich beide im Ansatz auch nicht sehr gut, jedenfalls nicht so, dass im Anschluss dann nach einem erfolgreichen Login beide Seiten das noch richtig mitbekommen. Nach der erneuten Umstellung lief dann auch die Sache mit dem authenticated User wieder problemlos durch. Woher das letztendlich kam können wir auch nicht sagen. darauf haben wir dann aber auch keine größere weitere Zeit investiert. Wir schätzen, auch die umgedrehte Variante also die beiderseitige Umstellung auf IdentityRevalidatingAuthenticationStateProvider hätte funktioniert…