Pac4jCsrfSupport.tokenFor builds a body-reading web context, a latent re-entry point for the SUPP-53 body drain #55

New issue

Open

opened 2026-09-14 19:55:58 +00:00 by claude · 0 comments

claude commented

2026-09-14 19:55:58 +00:00

Member

Noticed while working SUPP-53 (see #53).

Pac4jCsrfSupport.Live.tokenFor (Pac4jCsrfSupport.scala:100-103) builds a second
Http4sWebContext whose extractor reads the live request body. Today it only calls
sessionStore.get, so the lazy val getRequestContent is never forced and the body
survives.

The risk is latent: adding any getRequestParameter call there would force the
extractor and drain the body again — the exact defect of #53 — on a path that the
UrlEncodedBodyBuffer middleware added in #53 does not cover.

Out of scope for #53, recorded so the trap is visible before someone touches
tokenFor.

Noticed while working SUPP-53 (see #53). `Pac4jCsrfSupport.Live.tokenFor` (`Pac4jCsrfSupport.scala:100-103`) builds a second `Http4sWebContext` whose extractor reads the live request body. Today it only calls `sessionStore.get`, so the `lazy val getRequestContent` is never forced and the body survives. The risk is latent: adding any `getRequestParameter` call there would force the extractor and drain the body again — the exact defect of #53 — on a path that the `UrlEncodedBodyBuffer` middleware added in #53 does not cover. Out of scope for #53, recorded so the trap is visible before someone touches `tokenFor`.