CsrfRequestDataValueProcessor uses a different attribute name then the rest of the CSRF parts.

When working with Spring Webflux and CSRF protection additional steps are needed to expose the CSRF Token to the frontend. The reference guide mentions an @ControllerAdvice (which will only work for controllers) if you also have RouterFunction materials you need to add an additional HandlerFilterFunction so it copies the thing around.

When combining different ways of configuring endpoiints, it all adds up with additional cruft to have in place for a proper working of the CSRF tokens. Wouldn't it be easier for the CsrfRequestDataValueProcessor to utilize the same name CsrfToken.class.getName() to obtain the actual CsrfToken and expose it as hidden fields?

I wonder why the discrepancy with the regular CSRF protection and the additional (complexer) setup. As the servlet variant of the CsrfRequestDataValueProcessor does actually use the "proper" attribute name.