Fix Blazor template bug where a logged in user could appear to be unauthenticated

[halter73]

Description

A customer reported that after enhanced navigation from a WebAssembly-rendered component that does not require authentication state to another WebAssembly-rendered component that does, the client will lose its authentication state. This leads to issues where the server knows the client is authenticated meaning the client can navigate to components that require authentication, but the client thinks the user is unauthenticated for the purposes of rendering something like:

<AuthorizeView>
    <Authorized>
        <p>You are authorized</p>
        Hello @context.User.Identity?.Name!
    </Authorized>
    <NotAuthorized>
        <p>You are not authorized</p>
    </NotAuthorized>
</AuthorizeView>

This was caused by the PersistentAuthenticationStateProvider on the client attempting to read the UserInfo from PersistentComponentState after enhanced navigation. At this point the state from the original page load (/counter in the examples below) is cleared, and the state that was persisted during the enhanced navigation to /auth is simply ignored and never read by anyone despite calling the RegisterOnPersisting callback and rendering the state for each enhanced navigation. The PersistentComponentState behavior is by design according to @javiercn, and we can make auth work reliably with the current PersistentComponentState behavior by greedily reading the UserInfo during initial render before any enhanced navigation which is what this PR does.

Fixes #51368

Customer Impact

This was thankfully reported by a customer trying out the new Identity Blazor components in RC2. It's possible to get into this state with just the template code if a browser session starts in (or reload on) the template's /counter page and then does enhanced navigation to a component that uses an <AuthorizeView> like the template's /auth page. Without this fix, the user is forced to refresh the /auth page or any other page with <AuthorizeView> before they can see any rendered content that requires authorization.

auth-persistent-state-bug-refresh.mp4

Notice how the second time I navigate to the "Auth Required" page after refreshing on the "Counter" page, you see "You are authenticated" followed by "You are not authorized" even though any authenticated user should be authorized to see that page. After the fix, you always see "You are authenticated" followed by "You are authorized" and "Hello {email}!" as expected.

auth-persistent-state-fix.mp4

Regression?

• Yes
• No

Risk

• High
• Medium
• Low

This is a small change to a single Blazor Identity template component added in RC 2 which slightly simplifies the logic.

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

[ghost]

Hi @halter73. If this is not a tell-mode PR, please make sure to follow the instructions laid out in the servicing process document.
Otherwise, please add tell-mode label.

[javiercn]

PersistentComponentState does not live past the first enhanced navigation during interactive WebAssembly rendering. This is true even if the state is persisted for both the page being navigated to and from, and appears to be due to some sort of bug in PersistentComponentState, but we can work around the issue by always reading the persisted state in the PersistentAuthenticationStateProvider before any enhanced navigation occurs.

PersistentComponentState is only available during the first render by design. It's available only when a given runtime starts.

[ghost]

Hi @halter73. Please make sure you've updated the PR description to use the Shiproom Template. Also, make sure this PR is not marked as a draft and is ready-to-merge.

To learn more about how to prepare a servicing PR click here.

[ghost]

Hi @halter73. This PR was just approved to be included in the upcoming servicing release. Somebody from the @dotnet/aspnet-build team will get it merged when the branches are open. Until then, please make sure all the CI checks pass and the PR is reviewed.