对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 beforeapplication.yml
.
It is typically used for the following:
- when using Spring Cloud Config Server, you should specify
spring.application.name
andspring.cloud.config.server.git.uri
insidebootstrap.yml
- some
encryption/decryption
informationTechnically,
bootstrap.yml
is loaded by a parent SpringApplicationContext
. That parentApplicationContext
is loaded before the one that usesapplication.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
Spring Cloud Documentation 包含此信息以及更多信息。
在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 问题解决
https://stackoverflow.com/questions/42822875/springboot-1-5-x-security-oauth2
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 toSecurityProperties.ACCESS_OVERRIDE_ORDER - 1
, crucial information is that defaultWebSecurityConfigurerAdapter
order is 100 (source).
So in before release 1.5.x OAuth2 resource server order was 3 which had higher priority thenWebSecurityConfigurerAdapter
.
After release 1.5.x OAuth2 resource server order is set toSecurityProperties.ACCESS_OVERRIDE_ORDER - 1
(it isInteger.MAX_VALUE - 8
I think) which has now definitely lower priority then basicWebSecurityConfigurerAdapter
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)
onWebSecurityConfigurerAdapter
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 权限管理的一些文档
https://docs.spring.io/spring-security/site/docs/current/reference/html/el-access.html
多个 ResourceService 共享一个 AuthorizationService,在多个服务的Controller 间相互调用(fegin)进行授权验证,Scope 丢失
https://github.com/spring-projects/spring-boot/issues/5096
注入其他项目中的feignClient出现无法被scan到(注入失败)
https://stackoverflow.com/questions/30241198/error-injecting-feignclient-from-another-project
https://github.com/spring-cloud-samples/feign-eureka/issues/2