Add WebFlux RequestDataValueProcessor

[rwinch]

Summary

We need to provide integration with WebFlux RequestDataValueProcessor

[danielfernandez]

Does this need any specific configuration steps besides @EnableWebFluxSecurity? Using 5.1.0.RC2, during view processing (and once authenticated), when executing org.springframework.security.web.reactive.result.view.CsrfRequestDataValueProcessor#getExtraHiddenFields(...) it tries to do this:

// DEFAULT_CSRF_ATTR_NAME == "_csrf"
CsrfToken token = exchange.getAttribute(DEFAULT_CSRF_ATTR_NAME);

...but there is nothing there. Instead, the only ServerWebExchange attribute that seems related is a Mono<CsrfToken> object, but with attribute name org.springframework.security.web.server.csrf.CsrfToken.

Am I missing anything? is it normal that the CSRF token is not at the _csrf exchange attribute during view execution, and instead only this (unresolved) Mono<CsrfToken> is there?

[rwinch]

Unfortunately, at the moment, users must expose the CSRF token as a request attribute for it to be found. This is also true for the Authentication.

@ControllerAdvice
public class SecurityControllerAdvice {
	private Mono<Principal> currentUser;

	@ModelAttribute
	Mono<CsrfToken> csrfToken(ServerWebExchange exchange) {
		Mono<CsrfToken> csrfToken = exchange.getAttribute(CsrfToken.class.getName());
		if (csrfToken == null) {
			return Mono.empty();
		}
		return csrfToken.doOnSuccess(token -> exchange.getAttributes()
				.put(CsrfRequestDataValueProcessor.DEFAULT_CSRF_ATTR_NAME, token));
	}

	@ModelAttribute("currentUser")
	User currentUser(@CurrentUser User currentUser) {
		return currentUser;
	}
}

The reason is that we don't know if the user needs the CSRF token, so we cannot subscribe to the Mono<Csrf> on their behalf (which triggers it to be saved and thus a session created). We also cannot resolve a Mono<CsrfToken> in CsrfRequestDataValueProcessor because its methods arenot reactive types. The thought was that we cannot have a reactive type because the view (i.e. Thyemeleaf) would not be able to subscribe to it. Perhaps you have some ideas around this current limitation?

cc @rstoyanchev

[danielfernandez]

Perhaps you have some ideas around this current limitation?

Please see my comment on #5867. Version 3.0.10 of thymeleaf and thymeleaf-spring5, in combination with version 3.0.3 of thymeleaf-extras-springsecurity5 should be able to resolve this Mono<CsrfToken> using the mechanism just developed for being able to resolve the Mono<SecurityContext> in a non-blocking manner. Note however that unfortunately this means the CsrfToken will be resolved for every template being rendered.