[Validation] Analyzer diagnostics for authentication state

[oroztocil]

Scenario contact: @ilonatommy

Scenario

A component that reads the signed-in user once keeps showing the old user after sign-in or sign-out, because it never asked to be told when that changes. The symptom appears far from the cause: stale names, stale roles, and content shown to the wrong person. This validates that the build now warns about it, and that following the advice actually fixes the behavior.

Minimum build

.NET 11 Preview 7 or later.

Configurations to cover

• Blazor Web App
  • Static SSR
  • Interactive Server
  • Interactive WebAssembly
  • Interactive Auto
• Standalone WebAssembly
• Hybrid (MAUI)

These diagnostics are produced by the compiler, so they do not vary by render mode. The configuration below is the one needed to reproduce the runtime behavior the warning predicts, not a matrix to work through.

Also exercise

• Published output
• An existing .NET 10 app upgraded to .NET 11
• Trimming or ahead-of-time compilation
• More than one server instance, or a proxy in front
• Hot Reload
• An IDE as well as the command line
• Container

Setup

The app needs authentication that you can sign in and out of while it is running, so that the signed-in user genuinely changes without a full reload.

The diagnostic this scenario covers is:

Id	Title	Code fix
BL0013	AuthenticationStateProvider.GetAuthenticationStateAsync used without subscribing to AuthenticationStateChanged	No

What to build

Two places that read the signed-in user, because the reported problem covers both:

• A component that calls GetAuthenticationStateAsync once when it starts, stores the user in a field, and shows the name and roles, without subscribing to AuthenticationStateChanged.
• A DI service that does the same: injects AuthenticationStateProvider, caches the resulting user in a field, and hands it out to whatever asks. Register it as scoped and call it from a page.

Put <AuthorizeView> and <CascadingAuthenticationState> alongside them. Those two subscribe internally, so they keep up with changes and give you a live comparison on the same page.

Add a component that subscribes properly and unsubscribes on disposal, so a correct version sits next to the broken ones.

Things to try

• Building at the command line and in an IDE, and reading the messages that appear.
• Signing in and out while the page is open, without reloading the browser.
• Comparing what the component, the service and the <AuthorizeView> show at the same moment.
• Subscribing to AuthenticationStateChanged in both the component and the service, then repeating the sign-in and sign-out test.
• The correctly written component, to confirm it produces no warning.
• Reading the state from a cascading parameter instead, to see whether that is flagged.
• Navigating away from the page and back after signing in as a different user.

Expected behavior

The problem is reported at build time in both a component and a service, and subscribing fixes the runtime behavior the warning predicted.

Must hold

• Both the component and the service produce a BL0013 warning at the correct line. The service matters: a cached user in a long-lived service is the case the report called out alongside components.
• Before subscribing, both still show the previous user after signing in or out, while <AuthorizeView> on the same page shows the new one.
• After subscribing, both track the signed-in user without a reload.
• The correctly written component produces no BL0013 warning, and neither does <AuthorizeView> or <CascadingAuthenticationState>.
• The warning appears both at the command line and in the IDE, at the same line.

Expected differences between configurations

• None. The warning is produced at compile time and is identical in every configuration.

Documentation to use

• AuthenticationStateProvider service

What to report

Report results using the format described in the validation testing manual. Include link to a repository with the test app.

[irfanajaffer]

Test report

• Build tested: 11.0.100-preview.7.26381.103
• Configuration tested: Blazor Web App with Interactive Server rendering
• Also exercised: Visual Studio and command-line builds, Release publish, navigation without a full reload
• OS, browser, IDE: Windows, Microsoft Edge, Visual Studio 2022, PowerShell 5.1
• Sample app: irfanajaffer/StaleAuthStateSample
• Outcome: works as expected

Checks

Check	Result	Evidence
A component that calls GetAuthenticationStateAsync once without subscribing produces BL0013	Pass	StaleUserBadge produces BL0013 at the generated Razor call site
A scoped service that caches authentication state without subscribing produces BL0013	Pass	CachedUserService produces BL0013 at Services/CachedUserService.cs(6,21)
Unsafe consumers remain stale during continuous Anonymous → Alice → Bob → Sign-out changes	Pass	Both remain anonymous without navigation or reload
Subscribed and framework consumers track authentication changes	Pass	Live consumers, cascading state, and AuthorizeView show the current user and roles
Correct consumers produce no BL0013 warning	Pass	No warning for LiveUserBadge, LiveCachedUserService, CascadingUserBadge, AuthorizeView, or CascadingAuthenticationState
Warnings appear at the same locations in the IDE and command line	Pass	Visual Studio rebuild and command-line rebuild report the same two diagnostics

The command-line rebuild succeeded with exactly 2 BL0013 warnings and 0 errors. The warnings identify CachedUserService and the generated Razor call site for StaleUserBadge. No other compiler warnings were reported.

Additional coverage

Case	Expected	Result	Observation
Navigate away and return in the same circuit	StaleUserBadge is recreated with the current user; scoped CachedUserService keeps its original user; live consumers show current state	Pass	The recreated badge initially shows the current user, while the scoped service remains anonymous
Change user after returning from navigation	The recreated StaleUserBadge becomes stale again; live consumers update	Pass	The next identity change leaves the badge at the identity captured during recreation
Change from one authenticated identity to another	Live consumers update the user and role	Pass	Alice / Administrator changes to Bob / Support
Unsubscribe on disposal	Correct consumers remain warning-free	Pass	Both subscribed implementations detach their event handlers
Release publish	Build-time diagnostic remains present	Pass	Published Release output completes with the expected diagnostics

The Alice, Bob, and sign-out screenshots are independent navigation/recreation captures, not a continuous sequence. The continuous sequence was tested separately without navigation.

Evidence: command-line build, Visual Studio Error List, initial state, Alice, Bob, sign-out, navigation return, and fixed build.

The zero-warning build can be reproduced with the preserved files under evidence/fixed-source:

Copy-Item evidence/fixed-source/* . -Recurse -Force
dotnet build StaleAuthStateSample.slnx -t:Rebuild -nologo -v:minimal

Problems

None.

Documentation

The ASP.NET Core Blazor authentication state documentation describes consuming authentication state through a cascading parameter and reacting to AuthenticationStateChanged. It does not currently mention diagnostic ID BL0013.