.Net 10 Blazor Server Login in single page checkout

[Julien-Marpault]

Hello, I'm actually working on an e-commerce website.
The checkout page is a single page showing checkout steps one after other.
The first step is to signup or signin if not authenticated.

The user enters his username and password and submit.
Informations are submitted to SigninManager and I get this exception:
Unhandled exception rendering component: Headers are read-only, response has already started.

So I changed the way to access this page forcing reloading of the application in the navigationmanager in order to be in the same context as redirection to classic login page. The issue remains.

Is there a way to call this page to be int the same context than the login page and avoid the error ?

Thanks.

[vasgodutyal]

The important difference is the request that performs the sign-in, not how you navigated to the checkout page.

With cookie-based Identity, PasswordSignInAsync needs to send Set-Cookie to the browser. An Interactive Server event handler runs over the existing Blazor circuit; it is not a fresh browser HTTP response on which a login cookie can be issued. forceLoad: true reloads the page, but if that page becomes interactive again, its subsequent submit handler has the same problem. Disabling prerendering does not fix that boundary either.

For a checkout flow, I would use one of these approaches:

1. Reuse the template's account login and return to checkout. Preserve the cart/draft, navigate to Account/Login?ReturnUrl=%2Fcheckout, and let the normal Identity flow return to the checkout route after successful sign-in. The account page must retain its static SSR behavior. In a globally interactive app, copying only its form into an interactive checkout component does not preserve that behavior.
2. Keep the login UI visually inside checkout, but submit it through a real browser HTTP POST. Handle it in a Razor Page/controller (or a correctly configured static SSR form), issue the cookie there, then redirect back to checkout. For a browser-side fetch implementation, reload the document after success so a new circuit starts with the new authenticated principal. Calling the endpoint with a server-side HttpClient from the component won't install its cookie in the user's browser.

Keep antiforgery validation, local return-URL validation, and the normal Identity outcomes (including two-factor authentication and lockout). Store checkout state independently of the current circuit so the reload does not discard it.

Also check for streaming rendering on a static SSR login path: sending the response before sign-in completes can produce the same exception.

The HttpContext guidance explicitly covers this exception. A useful reference implementation is the Components/Account/Pages/Login.razor generated by dotnet new blazor -au Individual with the .NET 10 SDK: its form posts over HTTP and handles the different sign-in outcomes.