Fix CSRF middleware not setting token when Sec-Fetch-Site passes

[veeceey]

Summary

Fixes #2874

When checkSecFetchSiteRequest() returns (true, nil) — e.g. for direct URL navigation where Sec-Fetch-Site: none, or same-origin requests — the CSRF middleware immediately calls return next(c) without:

1. Generating or retrieving the CSRF token
2. Setting the CSRF cookie
3. Storing the token in context via c.Set(config.ContextKey, token)
4. Adding the Vary: Cookie response header

This breaks all server-rendered forms that use c.Get("csrf") to embed a CSRF token in HTML for subsequent POST requests. The bug is triggered by every modern browser during direct navigation (typing a URL, clicking a bookmark, or following an external link), since browsers automatically send Sec-Fetch-Site: none in these scenarios.

Changes

• middleware/csrf.go: Extract token generation and cookie/context setting into a setTokenInContext helper closure, and call it in the Sec-Fetch-Site allow path before calling next(c). The existing legacy token path remains unchanged.
• middleware/csrf_test.go:
  • Add expectCookieContains assertion to the existing SecFetchSite=same-origin test case
  • Add two new table-driven test cases verifying cookie is set for Sec-Fetch-Site: none and same-origin GET requests
  • Add a dedicated TestCSRF_SecFetchSiteSetsTokenInContext regression test that verifies the token is accessible in context, the cookie is set, the Vary header is correct, and existing cookie tokens are reused

Test plan

• All existing CSRF tests pass (go test ./middleware/ -run TestCSRF -v)
• New regression tests pass for the exact scenario from the issue
• Full test suite passes with race detector (go test -race ./...)
• Verified the fix handles both new token generation and reuse of existing cookie tokens

🤖 Generated with Claude Code

[aldas]

I though I had already merged #2894 I would prefer that solution. @veeceey would this work?

[veeceey]

Thanks for the pointer! Yes, #2894 would work for this use case. I see that approach is more comprehensive since it handles the token generation in the success path of Sec-Fetch-Site check as well.

Happy to close this PR in favor of #2894 if you'd prefer to go with that solution. Let me know!