Blazor Server手动实现授权码流时Cookie设置异常排查

抛出System.InvalidOperationException: Headers are read-only, response has already started的核心原因是你在Blazor Server的交互事件中直接操作HttpContext.Response写入Cookie，违反了Blazor Server的运行机制：

• Blazor Server首次页面加载完成后，服务端和浏览器的所有交互（包括按钮点击、组件生命周期方法执行）都走SignalR WebSocket长连接传输，初始的HTTP请求-响应流程早就结束，响应头已经完整发送到浏览器，处于只读不可修改的状态。
• 你代码里CreateSession()写入userId Cookie、Connect()方法写入state Cookie的逻辑，都是在按钮点击触发的事件中执行的，此时处于SignalR通信回路，不存在可修改的HTTP响应上下文，调用Response.Cookies.Append尝试向响应头添加Set-Cookie字段必然触发异常。
• 你当前在Blazor组件OnInitializedAsync中处理授权回调的逻辑也存在同样风险：如果组件已经开始渲染、向响应流写入内容，再操作响应头修改Cookie或者做跳转，同样会触发该异常。

你不需要调整整体的授权码流程设计，只要把涉及HTTP响应修改的逻辑从Blazor组件/交互事件层移到普通HTTP请求管道中即可，这种调整反而更贴近真实生产环境的授权码流程链路，适合演示场景：

1. 会话Cookie初始化移到_host页面处理 #

userId是用户首次访问站点就需要生成的会话标识，不要在点击事件里创建，直接放到Blazor应用的宿主页面_Host.cshtml的页面加载逻辑中，这时候是普通HTTP GET请求，响应还未启动，可以安全写入Cookie：

@page "/"
@namespace YourDemoApp.Pages
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers
@{
    Layout = "_Layout";
    // 首次访问时写入userId会话Cookie
    if (!Request.Cookies.TryGetValue("userId", out _))
    {
        Response.Cookies.Append("userId", Guid.NewGuid().ToString(), new CookieOptions
        {
            HttpOnly = true,
            IsEssential = true,
            SameSite = SameSiteMode.Lax
        });
    }
}
<component type="typeof(App)" render-mode="ServerPrerendered" />

2. 授权发起逻辑移到独立HTTP端点 #

不要在Connect服务中直接拼接IdP地址跳转，先跳转到本地的一个普通Razor Pages/ MVC控制器端点，在这个端点里完成state生成、state Cookie写入、授权地址拼接、最终跳转IdP的逻辑：

• 首先修改ConnectService.Connect()方法，只做本地端点跳转，加上forceLoad: true强制走完整HTTP请求，不走SignalR：

public async Task Connect()
{
    _navigationManager.NavigateTo("/Auth/StartAuth", forceLoad: true);
}

• 新增/Auth/StartAuth端点处理授权前逻辑：

// Pages/Auth/StartAuth.cshtml.cs
public class StartAuthModel : PageModel
{
    public IActionResult OnGet()
    {
        // 生成state参数
        var state = Guid.NewGuid().ToString();
        // 普通HTTP请求上下文，可安全写入Cookie
        Response.Cookies.Append("state", state, new CookieOptions
        {
            HttpOnly = true,
            SameSite = SameSiteMode.Lax,
            Expires = DateTimeOffset.Now.AddMinutes(10) // state短有效期即可
        });
        // 拼接授权请求参数
        var authorizeArgs = new Dictionary<string, string>
        {
            {"client_id", "你的演示客户端ID"},
            {"scope", "openid profile your_demo_scope"},
            {"redirect_uri", $"{Request.Scheme}://{Request.Host}/Auth/ConnectCallback"},
            {"response_type", "code"},
            {"state", state}
        };
        var authUrl = QueryHelpers.AddQueryString("你的IdP授权端点地址", authorizeArgs);
        // 跳转到IdP授权页
        return Redirect(authUrl);
    }
}

如果你想进一步简化流程，也可以省略state Cookie写入步骤：直接把state存在服务端内存缓存中，用已存在的userId作为key关联即可，全程不需要在交互阶段操作响应。

3. 授权回调逻辑移到独立HTTP端点 #

不要在Blazor组件的OnInitializedAsync中处理code换token、state校验的逻辑，同样把/Auth/ConnectCallback实现为普通Razor Pages/ MVC端点：

// Pages/Auth/ConnectCallback.cshtml.cs
public class ConnectCallbackModel : PageModel
{
    private readonly IMemoryCache _memoryCache;
    private readonly IHttpClientFactory _httpClientFactory;

    public ConnectCallbackModel(IMemoryCache memoryCache, IHttpClientFactory httpClientFactory)
    {
        _memoryCache = memoryCache;
        _httpClientFactory = httpClientFactory;
    }

    public async Task<IActionResult> OnGetAsync(string code, string state)
    {
        // 校验state合法性
        if (!Request.Cookies.TryGetValue("state", out var savedState) || savedState != state)
        {
            throw new AuthenticationException("State校验失败，请求可能被篡改");
        }
        // 校验通过后立即删除state Cookie，防止重放攻击
        Response.Cookies.Delete("state");
        
        // 省略code换access_token的HTTP请求逻辑
        var accessToken = "从IdP换取到的access_token";
        
        // 关联userId和access_token存入内存缓存
        if (Request.Cookies.TryGetValue("userId", out var userId))
        {
            _memoryCache.Set(userId, accessToken, TimeSpan.FromMinutes(30));
        }
        // 认证完成，跳转到业务页面
        return Redirect("/mypage");
    }
}

调整后的流程完全保留了授权码流程的全链路逻辑：用户点击Connect按钮 -> 跳本地授权发起端点 -> 生成state种Cookie -> 跳IdP授权 -> IdP回调本地端点 -> 校验state -> 用code换token -> 存储token关联用户 -> 跳业务页面，链路逻辑比在Blazor组件内处理更清晰，完全满足演示需求，也不会再出现响应只读的异常。

内容的提问来源于stack exchange，提问作者eduard