Summary
I cannot get Spring-Security to log anything in a simple Spring-Boot WebFlux application. I assume I must be doing something wrong because my searches have only turned up this unanswered SO question.
Actual Behavior
No Spring-Boot logging entries appear in terminal window after running ./gradlew bootRun.
Expected Behavior
Detailed logging entries as if using MVC. I followed the same steps to reproduce as shown below, substituting "Web" for "Reactive Web," and it works as expected.
Configuration
macOS 10.13.6 java version "1.8.0_181"
Version
I tried Spring-Booot versions 2.0.4, 2.1.0.M2, and 2.1.0.SNAPSHOT.
Sample
https://github.com/kensiprell/webflux-spring-security-demo
Steps to Reproduce
-
Go to https://start.spring.io.
-
Choose Gradle, Kotlin or Java, and a Boot version.
-
Add 'Security' and 'Reactive Web' to the dependencies and generate the project.
-
Unarchive demo.zip and
cd demo/. -
Edit
./src/main/resources/application.propertiesand add a line that should increase the logging level:logging.level.root=DEBUGorlogging.level.org.springframework.security=DEBUG -
./gradlew bootRun -
Open http://localhost:8080 in a browser.
Comment From: rwinch
You are not doing anything wrong. There really isn't any logging enabled within Spring Security's reactive support. Much of this has to do with the fact that the logging is likely a blocking operation. When I discussed this previously with the Reactor team they had said that there were thoughts around supporting reactive logging, but I just had not followed up on that. It seems like the recommendation is still to configuring logging to be async and that this is a limitation. We can and should add logging to Spring Security.
Comment From: wtatum
I think I have a good understanding of what makes this so challenging to resolve, but I'd like to quickly voice concern that this isn't being looked into more. There are some use cases that are inherently reactive in nature (a good example is Spring Cloud Gateway) but also strongly benefit from a traceable, auditable security framework.
I also understand the the framework authors can't always "compromise" in the system design, but I think end application often find it acceptable to make small compromises from reactive first principles (i.e. including small potentially blocking calls i.e. logger.debug in their otherwise reactive code. If I need to patch audit logging into my reactive application prior to this ticket being address do you have any advice for me? Is wrapping the existing imperative bean in a Mono.fromCallable or similar enough to "get by".
Comment From: KantarBenedictAdamson
I came here because I wanted some logging... but the reason I wanted that was that I am trying to debug a failing unit test. So if providing good logging for reactive Spring Security is too difficult for technical reasons, in some circumstances providing better debugging and testing support can be a mitigation.
Comment From: dillius
Are there any alternative recommendations for debugging security issues until the Reactor team has time to give this some thought?
I'm trying to debug CSRF issues and it is basically guesswork.
Comment From: ZhuBicen
Any progress?
Comment From: fee1good
Guys, really need to have logging security support :)
Comment From: samhaque
Is there any work around for the time being? I have a spring cloud gateway project being deployed to PCF and require logging for a ReactiveAuthenticationManager implementation.
Comment From: rwinch
Any volunteeers for a/some Pull Requests?
Comment From: mouellet
Hey @rwinch, I've been looking into this and I think if we add some doOnNext here and there (i.e. Filters, Matchers, EntryPoint, etc.), we'll have about the same output as we have on the servlet side.
As for the FilterChainProxy logging (i.e. / at position x of y in additional filter chain; firing Filter: '***Filter'), should this be added in spring-web's DefaultWebFilterChain instead of re-implementing it just to add logs? Or is it specific to spring security?
I'll start working on this and have a PR ready soon!
Comment From: rwinch
should this be added in spring-web's DefaultWebFilterChain instead of re-implementing it just to add logs? Or is it specific to spring security?
We should try to update Spring Framework rather than re-implement things. I'd create a ticket on their side and coordinate with them.
I'll start working on this and have a PR ready soon!
Thanks @mouellet! The issue is yours.
Comment From: rwinch
I closed this in favor of gh-8504