These are chat archives for spring-cloud/spring-cloud

9th
May 2017
William Witt
@unamanic
May 09 2017 13:41
We recently upgraded versions of Spring and wanted to replace a custom RequestInterceptor with OAuth2FeignRequestInterceptor. However, there are a couple of unsecured paths through our microservices (an unsecured call to Service A calls an unsecured endpoint on Service B). Using the OAuth2FeignRequestInterceptor cases the calls from Service A to fail due to a missing token even when the endpoint doesn't require it. Is this a bug in OAuth2FeignRequestInterceptor or are we using it outside of its intended usecase?
Dave Syer
@dsyer
May 09 2017 16:30
Maybe you need a second Feign client?
Or we can think of a way to ignore unsecured requests
William Witt
@unamanic
May 09 2017 16:45
Would it be more appropriate to just not pass a token if one isn't present in the security context, and handle the failure in the response if the call requires authentication? (Rather than throwing an exception on line 156 https://github.com/spring-cloud/spring-cloud-security/blob/master/spring-cloud-security/src/main/java/org/springframework/cloud/security/oauth2/client/feign/OAuth2FeignRequestInterceptor.java#L156 )
Dave Syer
@dsyer
May 09 2017 16:49
Maybe. Propose a change in a PR?
William Witt
@unamanic
May 09 2017 16:51
But the root of my question is, are we using OAuth2FeignRequestInterceptor inappropriately? Is/was the intent to assume that if one were defined, that all requests would be secured (barring other config)? If so, we'll take a different course. If not we can do a PR.
Dave Syer
@dsyer
May 09 2017 17:20
I don't think that can have been the intent. But defining what you mean by intentionally insecure and what is just unauthenticated might be a challenge.
We have the "proxy.auth" config settings to go by. Anything that uses those would be a good idea.