java.lang.StackOverflowError: null when an invalid token is sent to an oauth2ResourceServer #8369
Comments
spring-projects-issues
added
the
status: waiting-for-triage
jzheaux
added
in: oauth2
|
Sorry that you are having trouble, @santam85. With the information shared so far, I'm unable to reproduce the issue. Would you please put together a minimal sample that reproduces the issue? |
jzheaux
added
the
status: waiting-for-feedback
|
Yes, will create a repo ASAP... |
spring-projects-issues
added
status: feedback-provided
rwinch
added
status: waiting-for-feedback
|
Here's a minimal reproduction sample. Perhaps some of the security configuration can be further simplified. https://github.com/santam85/spring-boot-8369 To reproduce the issue, I send a request to any of the authenticated urls with an |
spring-projects-issues
added
status: feedback-provided
|
Thanks, @santam85, that was helpful, I will play around with this more. What do you need to expose the |
jzheaux
added
status: waiting-for-feedback
I tried removing it and I couldn't reproduce the problem anymore, so it's definitely related. |
|
Thanks, @santam85. I think there is a configuration cycle that may take some time to unravel correctly. There are a couple of workarounds that you can use in the meantime, which I'll list below.
protected configure(AuthenticationManagerBuilder builder) {
// empty
}Actually, any configuration here will suit, but since
@Bean
@Override
public UserDetailsService userDetailsService() {
return username -> {
throw new UnsupportedOperationException("unsupported");
}
}Publishing a protected configure(AuthenticationManagerBuilder auth) {
auth.userDetailsService(...);
}So, really it's just a corollary to the first workaround. The reason this came up with the OAuth 2.0 support is that other authentication mechanisms like More specific to your use case, you could consider if there is a smaller Spring Security component that your @Bean
AuthorizationPolicy policy(JwtDecoder jwtDecoder) {
SpringSecurityAuthorizationPolicy policy = ...
JwtAuthenticationProvider provider = new JwtAuthenticationProvider(jwtDecoder);
policy.setAuthenticationManager(provider::authenticate);
// ...
return policy;
}Would you try these and let me know if it resolves the StackOverflowError? |
|
I tried workaround 1 successfully, thanks for your suggestion! I'll be watching the ticket for updates, thanks for the quick answer! |
|
Looks like the error has been there for a while: http://blog.iampfac.com/blog/2015/02/12/stackoverflow-error-with-spring-security-authentication/ It was fixed also using with the workaround 1) |
jzheaux
added
in: core
|
@jzheaux any updates on this? |
|
I'm afraid not, @santam85, though thanks for the bump. We'll be taking a look at deprecating
Can you clarify these points further? |
|
The endpoints protected by |
|
Most often, each provider works with a unique When your custom |
|
This is the class performing the call to |
This is caused by a bug/issue in Spring: spring-projects/spring-security#8369 The solution is to not a define a authenticationManager bean.
Hola buenas tengo un problema nose si me pueda ayudar tengo un error de referencia circular que sucede en mi "securityConfig" con mi controller logincontroller.package idat.pe.Examen.Security; import org.springframework.beans.factory.annotation.Autowired; import idat.pe.Examen.JWT.JwtRequestFilter; } import java.util.Date; import org.json.JSONObject; import idat.pe.Examen.DTO.PacienteDto; @RestController } yo pienso que mi error es en @Autowired@Lazy private AuthenticationManager authenticationManager; le puse @lazy para probar si es que se puede resolver el error por el tiempo de carga pero no funciona si me podrian ayudar se los agradeceria mucho |
|
Closing this in favor of #12343 since that issue has the explanation for the most common case of |
Summary
When using oauth2ResourceServer, I am getting a stackoverflow error if the application receives an invalid token
Actual Behavior
I see this error in the console and i get a 500 statusCode to my request
Expected Behavior
I get no stackTrace and a 401/403
Configuration
I could reproduce by using this configuration:
and sending an Authorization header of "Bearer 1234"
Version
5.2.3.RELEASE
The text was updated successfully, but these errors were encountered: