对SpringCloud做一次简单的问题总结。
application.yml 和 bootstrap.yml 有何区别？
I have just asked the Spring Cloud guys and thought I should share the info I have here.
bootstrap.yml is loaded before application.yml.
It is typically used for the following:
when using Spring Cloud Config Server, you should specify spring.application.name and spring.cloud.config.server.git.uri inside bootstrap.yml
some encryption/decryption information
Technically, bootstrap.yml is loaded by a parent Spring ApplicationContext. That parent ApplicationContext is loaded before the one that uses application.yml.
bootstrap.yml在application.yml之前加载。
通常用于以下几方面：
在使用 Spring Cloud Config Server时，应在bootstrap.yml中指定spring.application.name和spring.cloud.config.server.git.uri。
一些加密/解密信息。
技术方面，bootstrap.yml由父SpringApplicationContext加载。父ApplicationContext在使用application.yml之前加载。
Spring Eureka服务器在客户端url中找不到 Context-path
If your Eureka client is setup via Spring's @EnableEurekaClient, then the client will default the health check and status check to /health and /info respectively. (These paths may be the default values beyond the Spring @EnableEurekaClient setup, but I am unfamiliar with those at this point in time).
You can override these defaults by setting the following properties:
eureka.instance.statusPageUrlPath
eureka.instance.healthCheckUrlPath
The Spring Cloud Documentation contains this information, plus much more.
如果你的Eureka客户端是通过Spring的@EnableEurekaClient设置的，那么客户端将分别将健康检查(health check)和状态检查(status check)默认为/health 和 /info。
你可以通过设置以下属性来覆盖这些默认值：
eureka.instance.statusPageUrlPath
eureka.instance.healthCheckUrlPath
在eureka环境下如何正确设置spring boot admin客户端的 management.context-path
On the client:
eureka:
instance:
metadata-map:
management.context-path: ${management.context-path}
As described in the docs:
If you want to customize the default conversion of services you can either add health.path, management.port and/or mangament.context-path entries to the services metadata.
在客户端增加配置：
eureka:
instance:
metadata-map:
management.context-path: ${management.context-path}
如 文档中所述：
如果要自动已服务的 default conversion，可以将health.path、management.port和/或management.context-path条目添加到service metada中。
Spring Boot 升级 1.5.x(从 1.3.x)跳转 login 问题解决
Ok, I got it now.
@Cleto Gadelha pointed me very usefull info.
However I think release note is pretty unclear or miss some information. Beside that OAuth2 resource filter is changed from 3 to SecurityProperties.ACCESS_OVERRIDE_ORDER - 1, crucial information is that default WebSecurityConfigurerAdapter order is 100 (source).
So in before release 1.5.x OAuth2 resource server order was 3 which had higher priority then WebSecurityConfigurerAdapter.
After release 1.5.x OAuth2 resource server order is set to SecurityProperties.ACCESS_OVERRIDE_ORDER - 1
(it is Integer.MAX_VALUE - 8 I think) which has now definitely lower priority then basic WebSecurityConfigurerAdapter order.
That's why login page appears for me after migrate from 1.4.x to 1.5.x
So, more elegant and java-like style solution is to set @Order(SecurityProperties.ACCESS_OVERRIDE_ORDER) on WebSecurityConfigurerAdapter class
主要由于在1.5.x版本之前，OAuth2资源服务器Order为3，其优先级高于WebSecurityConfigurerAdapter。发布1.5.x后，OAuth2资源服务器顺序设置为SecurityProperties.ACCESS_OVERRIDE_ORDER - 1(我认为是Integer.MAX_VALUE - 8)，他的优先级现在肯定低于基本的WebSecurityConfigurerAdapter顺序。
这就是为什么从1.4.x迁移到1.5.x后，我会看到登陆页面的原因。
因此，更优雅和类似Java的样式解决方案是在WebSecurityConfigurerAdapter类上设置@Order(SecurityProperties.ACCESS_OVERRIDE_ORDER)。
关于 Spring Boot 权限管理的一些文档
多个 ResourceService 共享一个 AuthorizationService，在多个服务的Controller 间相互调用(fegin)进行授权验证，Scope 丢失
注入其他项目中的feignClient出现无法被scan到(注入失败)
)
