In one of our applications we have a couple of ApplicationListener implementations which operate on certain events from Spring Security. One is for logging and another is for disabling the user after a number of failed login attempts.
We noticed that the AuthenticationSuccessEvent and AuthenticationFailureBadCredentialsEvent where fired multiple times. After some debugging we noticed that there where chained ProviderManagers, the first only contained an AnonymousAuthenticationProvider, the second was empty and the third contained the DaoAuthenticationProvider. The last one failed to authenticate the user, which resulted in a failure and all ProviderManagers handling that exception.
We use Spring Boot for configuration (using OAuth2) and for that we use a form to authenticate the user, this resulted in that chain. After doing some modification to our configuration we managed to reduce the chain to 2 chained ProviderManagers instead of 3 (we eleminated the empty one) and this appears to resolve it.
However I wonder is this the intended behavior of should only the inner or outer most ProviderManager handle the exception?
Comment From: rwinch
@mdeinum Thanks for reporting the issue!
At first glance this appears to be a bug. We should only be firing a single event.
Any chance you would be interested in figuring out a PR for this?
Comment From: mdeinum
@rwinch I'll have a stab at it. First let me try to create a sample which replicates the behavior. Is there a spring-security-issues repository. I'm also wondering if this is a configuration issue (that it possible need not chain ProviderManagers )or a ProviderManager issue)
Comment From: rwinch
@mdeinum
Is there a *spring-security-issues` repository.
There is now :) https://github.com/spring-projects/spring-security-issues
I'm also wondering if this is a configuration issue (that it possible need not chain {{ProviderManager}}s )or a {{ProviderManager}} issue)
It is possible that this could be cleaned up, but I still think that the eventing should be a single event.
Comment From: mdeinum
@rwinch will create a small project (at least test case) that show the issues. Expect a pull request soon.
@rwinch The repo is empty, could you add a README or something so that I can fork it and create a pull request.
Comment From: rwinch
@mdeinum Thanks!
Comment From: mdeinum
@rwinch as the spring-security-issues repo is empty, I couldn't fork it. I have created a test that reproduces the effect and chain I see when using Spring Boot with Spring Security (and OAuth).
The test can be found on https://github.com/mdeinum/spring-security-issues/tree/gh-3714 .
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: mdeinum
As I provided the feedback (the sample) about 4 years ago, not sure why it still has this tag?
I'll see if I can rebase that branche against the current Spring Security version.
Comment From: mdeinum
After upgrading, the test went green... After trying different versions I concluded that this was fixed in the 5.1.3.RELEASE version of Spring Security. Not sure which commit fixed it (yet), but after that version the test is green.
So closing this ticket would be fine I guess.
Comment From: mdeinum
It was fixed with https://github.com/spring-projects/spring-security/commit/a02d6ad2a4157066b896208710790d6ac3d30655 (which actually states that it shouldn't fire multiple times) by @jgrandja. Who wrote more or less the exact same test case I figured out that time.
This was duplicated with #6281
So closing this issue as being already fixed.