Request-scoped beans do not work in the management context when it's using a separate port

Hi,

I have a question. We are using OAuth2 for securing our API’s including the management endpoints. However, we are having an issue when authenticating the requests for the management URL’s. Spring Security’s OAuth2AuthenticationManager requires at some point a request scoped OAuth2ClientContext. The problem is that this request scoped bean can not be created. It logs the following warning:

Could not fetch user details: class org.springframework.beans.factory.BeanCreationException, Error creating bean with name 'scopedTarget.oauth2ClientContext': Scope 'request' is not active for the current thread; consider defining a scoped proxy for this bean if you intend to refer to it from a singleton; nested exception is java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.

After googling this issue, it was suggested to make sure that the request is passing the RequestContextFilter. I was convinced that this was already done by Spring Boot’s auto configuration. Then I noticed that this filter is not used for actuator URL’s. The opposite is also true for non-actuator URL’s. Is there a reason why this filter is not automatically applied for actuator endpoints? What do I have to do to make sure that actuator endpoints also make use of that specific filter?

Additional info: Actuator endpoints are configured to be served on a different port and context root compared to the standard application endpoints.

[wilkinsona]

I see you’ve edited your original description to add the following:

Actuator endpoints are configured to be served on a different port and context root compared to the standard application endpoints.

As you’ve described, that’s a key piece of information as the problem doesn’t occur without the different port.

The above described behaviours was already present in version 1.5.x and is still the same for 2.x. So perhaps this is still a bug?

I’m not sure if we’ll consider it to be a bug, but it’s certainly something that I don’t think we’ve considered before. While we decide what to do, you can configure the separate management context with a RequestContextFilter by creating a class annotated with @ManagementContextConfiguration in a package that isn’t covered by component scanning:

package sample;

import org.springframework.boot.actuate.autoconfigure.web.ManagementContextConfiguration;
import org.springframework.context.annotation.Bean;
import org.springframework.web.filter.RequestContextFilter;

@ManagementContextConfiguration
public class ManagementFilterConfiguration {

	@Bean
	public RequestContextFilter requestContextFilter() {
		return new RequestContextFilter();
	}

}

And then listing it in a META-INF/spring.factories file:

org.springframework.boot.actuate.autoconfigure.web.ManagementContextConfiguration=sample.ManagementFilterConfiguration

[wilkinsona]

Let’s auto-configure the request context filter in the separate management context.