Spring Security灵活的PasswordEncoder加密方式

本章基于Spring Security 5.4.1版本编写,从5.x版本开始引入了很多新的特性。
为了适配老系统的安全框架升级,Spring Security也是费劲了心思,支持不同的密码加密方式,而且根据不同的用户可以使用不同的加密方式。

构建Spring Security项目

Spring Security的集成使用还是很简单的,根据项目使用的框架不同大致分为两种集成方式:

  • SpringBoot方式集成
  • SecurityBom方式集成

SpringBoot方式构建

pom.xml文件内添加如下内容:

1
2
3
4
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>

SecurityBom方式构建

spring-security-bom是一个提供了Spring Security指定版本的全部默认依赖的pom类型项目,我们可以通过dependencyManagement进行配置到项目中,这样我们就可以直接添加对应的dependency了(注意:版本号因为bom已经注定,所以dependency不需要指定.)。
pom.xml文件内添加如下内容:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<dependencies>
// ...省略其他依赖
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-config</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-core</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-web</artifactId>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<!--配置SecurityBom-->
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-bom</artifactId>
<version>5.4.1</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>

注意事项:我们构建Web类型的安全项目时,spring-security-configspring-security-corespring-security-web三个依赖都是必须添加的。

PasswordEncoder

PasswordEncoderSpring Security提供的密码加密方式的接口定义,源码类如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
public interface PasswordEncoder {

/**
* Encode the raw password. Generally, a good encoding algorithm applies a SHA-1 or
* greater hash combined with an 8-byte or greater randomly generated salt.
*/
String encode(CharSequence rawPassword);

/**
* Verify the encoded password obtained from storage matches the submitted raw
* password after it too is encoded. Returns true if the passwords match, false if
* they do not. The stored password itself is never decoded.
*
* @param rawPassword the raw password to encode and match
* @param encodedPassword the encoded password from storage to compare with
* @return true if the raw password, after encoding, matches the encoded password from
* storage
*/
boolean matches(CharSequence rawPassword, String encodedPassword);

/**
* Returns true if the encoded password should be encoded again for better security,
* else false. The default implementation always returns false.
* @param encodedPassword the encoded password to check
* @return true if the encoded password should be encoded again for better security,
* else false.
*/
default boolean upgradeEncoding(String encodedPassword) {
return false;
}
}
  • #encode

    该方法提供了明文密码的加密处理,加密后密文的格式主要取决于PasswordEncoder接口实现类实例。

  • #matches

    匹配存储的密码以及登录时传递的密码登录密码是经过加密处理后的字符串)是否匹配,如果匹配该方法则会返回true.

内置的PasswordEncoder实现列表

DelegatingPasswordEncoder

在之前版本集成Spring Secuirty时,我们需要通过@Bean的方式来配置全局统一使用的密码加密方式(PasswordEncoder),当然这种方式现在还是适用的,不过在5.x版本开始为了支持动态的多种密码加密方式,DelegatingPasswordEncoder委托加密方式类应用而生,它内部其实是一个Map集合,根据传递的Key(Key为加密方式)获取Map集合的Value,而Value则是具体的PasswordEncoder实现类。

DelegatingPasswordEncoder建立密码格式的规则,格式如:{bcrypt}encodePassword,示例如下所示:

1
2
3
4
5
6
7
8
9
// {bcrypt}格式会委托给BCryptPasswordEncoder加密类
{bcrypt}$2a$10$iMz8sMVMiOgRgXRuREF/f.ChT/rpu2ZtitfkT5CkDbZpZlFhLxO3y
// {pbkdf2}格式会委托给Pbkdf2PasswordEncoder加密类
{pbkdf2}cc409867e39f011f6332bbb6634f58e98d07be7fceefb4cc27e62501594d6ed0b271a25fd9f7fc2e
// {MD5}格式会委托给MessageDigestPasswordEncoder加密类
{MD5}e10adc3949ba59abbe56e057f20f883e
// {noop}明文方式,委托给NoOpPasswordEncoder
{noop}123456
// ...

指定用户使用PasswordEncoder

DelegatingPasswordEncoder是默认的PasswordEncoder加密方式,所以我们可以为不同的用户配置所使用不同的密码加密方式,只需要密码格式按照:{away}encodePassword来进行持久化即可。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
@Configuration
@EnableWebSecurity
public class WebSecurityConfiguration extends WebSecurityConfigurerAdapter {

@Override
protected void configure(HttpSecurity http) throws Exception {
http
.formLogin()
.and()
.csrf()
.disable()
.authorizeRequests()
.antMatchers("/**")
.authenticated();
}

@Bean
public UserDetailsService users() {
// {MD5}value必须大写,value值必须是32位小写
// admin
UserDetails admin = User.builder()
//.passwordEncoder(encoder::encode)
.username("admin").password(
"{MD5}e10adc3949ba59abbe56e057f20f883e"
).roles("admin").build();

// hengboy
UserDetails hengboy = User.builder()
.username("hengboy")
.password("{bcrypt}$2a$10$iMz8sMVMiOgRgXRuREF/f.ChT/rpu2ZtitfkT5CkDbZpZlFhLxO3y")
.roles("admin")
.build();

// yuqiyu
UserDetails yuqiyu = User.builder().username("yuqiyu")
//.password("{noop}123456")
.password("{pbkdf2}cc409867e39f011f6332bbb6634f58e98d07be7fceefb4cc27e62501594d6ed0b271a25fd9f7fc2e")
.roles("user").build();

return new InMemoryUserDetailsManager(admin, yuqiyu, hengboy);
}
}

上面是使用内存方式存储安全用户的实现代码,在创建UserDetailsService类的实例时将用户列表通过构造参数进行传递。

所创建的用户:admin,采用MD5的加密方式进行密码编码,这里需要注意的是MD5加密后的字符串必须为小写32位

所创建的用户:hengboy,采用bcrypt方式进行密码编码。

所创建的用户:yuqiyu,采用pbkdf2方式进行密码编码。

覆盖默认的PasswordEncoder

Spring Security 5.x版本默认的PasswordEncoder方式改成了DelegatingPasswordEncoder委托类,不过如果是通过PasswordEncoderFactories#createDelegatingPasswordEncoder方法创建的DelegatingPasswordEncoder实例时,默认其实使用的还是BCryptPasswordEncoder,源码如下所示:

1
2
3
4
5
6
7
8
public static PasswordEncoder createDelegatingPasswordEncoder() {
String encodingId = "bcrypt";
Map<String, PasswordEncoder> encoders = new HashMap<>();
encoders.put(encodingId, new BCryptPasswordEncoder());
// 省略...

return new DelegatingPasswordEncoder(encodingId, encoders);
}

如果我们项目中不需要使用DelegatingPasswordEncoder委托密码编码方式,可以通过@Bean的方式来统一配置全局共用的PasswordEncoder,如下所示:

1
2
3
4
@Bean
public PasswordEncoder passwordEncoder() {
return new BCryptPasswordEncoder();
}

可以根据项目自行选择所使用的PasswordEncoder实现类。

SpringBoot2.x基础篇:使用CommandLineRunner或ApplicationRunner

如果你想要使用SpringBoot构建的项目在启动后运行一些特定的代码,那么CommandLineRunnerApplicationRunner都是很好的选择。

推荐阅读

使用方式

我们以CommandLineRunner创建了一个简单的例子,如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
/**
* {@link CommandLineRunner}接口使用示例
*
* @author 恒宇少年
*/
@Component
public class CommandLineRunnerExample implements CommandLineRunner {
/**
* 实例化本类的日志采集器
*/
static LoggingCollector logging = LoggingCollectorFactory.getCollector(CommandLineRunnerExample.class);

@Override
public void run(String... args) throws Exception {
// 执行特定的代码
logging.debug("main方法参数列表:{}", args);
}
}

CommandLineRunner接口的定义很简单,只提供了一个名为#run()的方法,我们只需要实现该方法做一些自定义的业务逻辑即可,ApplicationRunner接口的使用方式也是一样的。

两者的区别?

从源码上分析,CommandLineRunnerApplicationRunner两者之间只有#run()方法的参数不一样而已。

CommandLineRunner:

1
2
3
4
5
6
7
8
9
10
11
@FunctionalInterface
public interface CommandLineRunner {

/**
* Callback used to run the bean.
* @param args incoming main method arguments
* @throws Exception on error
*/
void run(String... args) throws Exception;

}

ApplicationRunner:

1
2
3
4
5
6
7
8
9
10
11
@FunctionalInterface
public interface ApplicationRunner {

/**
* Callback used to run the bean.
* @param args incoming application arguments
* @throws Exception on error
*/
void run(ApplicationArguments args) throws Exception;

}

CommandLineRunner#run()方法的参数是启动SpringBoot应用程序main方法的参数列表,而ApplicationRunner#run()方法的参数则是ApplicationArguments对象。

在之前的文章中也提到过ApplicatgionArguments对象,并使用它获取外部的配置参数,查看:应用程序在启动时访问启动项参数

建议:如果你在项目启动时需要获取类似 “–xxx” 的启动参数值建议使用ApplicationRunner

什么时候会被调用?

我们已经了解CommandLineRunnerApplicationRunner两个接口的使用以及区别,是不是很想知道SpringBoot在启动时在什么时候调用它们的呢?

我们大家都知道SpringBoot应用程序的启动主要归功于SpringApplication这个类,我们在创建项目时在启动类内会调用SpringApplication#run()方法,如下所示:

1
2
3
public static void main(String[] args) {
SpringApplication.run(LoggingServiceApplication.class, args);
}

那我们来查看下SpringApplication#run()方法的源码,根据查看方法之间的相互调用,最终我们会定位到org.springframework.boot.SpringApplication#run(java.lang.String...)这个方法,阅读该方法时发现有关调用Runner的定义,如下所示:

1
2
3
4
// 省略部分源码
listeners.started(context);
callRunners(context, applicationArguments);
// 省略部分源码

#callRunnners()方法的调用确实是在应用程序启动完成后,而且把ApplicationContextApplicationArguments对象都作为参数进行了传递,那么我们来看看这个方法究竟干了些什么事情?

SpringApplication#callRunners:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
private void callRunners(ApplicationContext context, ApplicationArguments args) {
List<Object> runners = new ArrayList<>();
runners.addAll(context.getBeansOfType(ApplicationRunner.class).values());
runners.addAll(context.getBeansOfType(CommandLineRunner.class).values());
AnnotationAwareOrderComparator.sort(runners);
for (Object runner : new LinkedHashSet<>(runners)) {
if (runner instanceof ApplicationRunner) {
callRunner((ApplicationRunner) runner, args);
}
if (runner instanceof CommandLineRunner) {
callRunner((CommandLineRunner) runner, args);
}
}
}

我想大家看到这里就应该明白了,这个方法就是在执行CommandLineRunner以及ApplicationRunner实现类实例的#run()方法,首先会从ApplicationContext中获取CommandLineRunnerApplicationRunner接口实现类的实例,然后根据不同类型的Runner实例去调用了callRunner方法。

SpringApplication#callRunner:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// 调用ApplicationRunner实现类实例#run()
private void callRunner(ApplicationRunner runner, ApplicationArguments args) {
try {
(runner).run(args);
}
catch (Exception ex) {
throw new IllegalStateException("Failed to execute ApplicationRunner", ex);
}
}
// 调用CommandLineRunner实现类实例#run()
private void callRunner(CommandLineRunner runner, ApplicationArguments args) {
try {
(runner).run(args.getSourceArgs());
}
catch (Exception ex) {
throw new IllegalStateException("Failed to execute CommandLineRunner", ex);
}
}

设置执行顺序

那如果我们创建了多个CommandLineRunnerApplicationRunner实现类,还想要实现类在执行的时候有一定的先后顺序,那你不妨试下org.springframework.core.annotation.Order这个注解或者实现org.springframework.core.Ordered接口。

CommandLineRunnerExample:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
/**
* {@link CommandLineRunner}接口使用示例
*
* @author 恒宇少年
*/
@Component
@Order(100)
public class CommandLineRunnerExample implements CommandLineRunner, Ordered {
// 省略部分代码
@Override
public int getOrder() {
return 100;
}
}

接口注解的方式选择其中一种就可以了。

SpringBoot2.x基础篇:将静态资源打包为WebJars

概述

我们在编写前后分离项目时,前端的项目一般需要静态资源(ImageCSSJavaScript…)来进行渲染界面,而如果我们对外采用依赖的方式提供使用时,我们的静态资源文件也应该放入打包文件内,这样才能更便捷的提供我们的功能,在我的开源分布式日志框架 minbox-logging 内提供了管理界面的功能,就是采用的这种方式实现,将静态资源以及编译后HTML页面存放到minbox-logging-admin-ui依赖内,下面我们来看下具体的实现方式。

推荐阅读

了解Resources Static Locations

在我们打包静态资源前,首先来了解下SpringBoot提供的spring.resources.static-locations配置默认值,该配置用于配置ResourceHandler,项目启动后会将该参数的配置值列表作为直接可访问的静态目录进行映射,通过这种方式我们就可以直接访问到我们需要的静态资源内容。

spring.resources.static-locations配置位于org.springframework.boot.autoconfigure.web.ResourceProperties配置类内,其默认值是使用本类内的静态常量CLASSPATH_RESOURCE_LOCATIONS的值,如下所示:

1
2
3
4
5
6
7
8
private static final String[] CLASSPATH_RESOURCE_LOCATIONS = { "classpath:/META-INF/resources/",
"classpath:/resources/", "classpath:/static/", "classpath:/public/" };

/**
* Locations of static resources. Defaults to classpath:[/META-INF/resources/,
* /resources/, /static/, /public/].
*/
private String[] staticLocations = CLASSPATH_RESOURCE_LOCATIONS;

通过查看源码我们得知,classpath:/META-INF/resources/目录下的资源是可以直接通过默认的映射绑定关系访问到的,通过这一点,我们可以将静态资源依赖内的资源文件存放到META-INF/resources目录下。

资源打包

我们使用Maven方式构建一个普通的项目,在pom.xml文件内添加资源目录配置,在编译过程中将src/main/resources目录下的文件全部复制到META-INF/resources下,如下所示:

1
2
3
4
5
6
7
8
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<targetPath>META-INF/resources</targetPath>
</resource>
</resources>
</build>

为了验证资源访问,我们在src/main/resources目录下存放一个名为head.jpg的图片。

我们为了本地演示使用,将Maven项目通过mvn install命令安装到本地仓库,以便于提供给其他项目使用。

使用WebJars依赖

我们来创建一个SpringBoot项目,在项目的pom.xml文件内添加如下依赖:

1
2
3
4
5
6
7
8
9
10
11
12
<dependencies>
<!--静态资源的访问映射绑定需要web依赖-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.example</groupId>
<artifactId>webjars-sample</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>

由于我们在之前通过mvn install命令将静态资源项目安装到了本地仓库,所以我们可以使用依赖。

通过IDEA工具我们可以查看webjars-sample依赖内的资源文件,如下图所示:

由于SpringBoot提供的spring.resources.static-locations参数默认值,会将classpath:/META-INF/resources目录作为静态资源映射,所以我们可以直接进行访问head.jpg文件。

运行SpringBoot项目,通过访问 http://localhost:8080/head.jpg,效果如下图:

静态资源访问前缀

我们在访问静态资源的时候并没有直接加前缀,而是通过ip:port/head.jpg直接访问,这主要是SpringBoot还提供了另外一个配置spring.mvc.static-path-pattern,其作用是用来配置静态资源的访问前缀,默认值为/**,如果需要修改直接在application.yml文件内进行赋值即可,

application.yml配置文件,如下所示:

1
2
3
4
5
spring:
application:
name: example
mvc:
static-path-pattern: /static/**

我们修改了spring.mvc.static-path-pattern配置的值为/static/**,当我们重启项目后需要通过 http://localhost:8080/static/head.jpg 才可以访问到资源。

总结

如果你有一些资源不希望被别人修改,让使用者更加便利的集成时,可以采用这种方式来封装自己的webjars,只需要添加依赖引用就可以访问到静态资源,也可以将静态HTML网页通过这种方式打包。

SpringBoot2.x基础篇:谈谈SpringBoot内提供的这几种配置绑定

常见配置绑定方式

SpringBoot在不断地版本迭代中陆续提供了不同的配置参数绑定的方式,我们可以单独获取一个配置参数也可以将一系列的配置映射绑定到JavaBean的属性字段,下面我们来看看这几种方式的配置绑定哪一种是你最常用到的。

示例配置参数

1
2
3
4
system:
config:
app-id: hengboy
app-secret: yuqiyu@admin

上面是一段示例的配置参数,提供给下面的配置绑定方式来使用。

@Configuration方式绑定

当我们需要将一个配置前缀下的参数映射绑定到JavaBean的属性字段时,我们可以考虑使用@ConfigurationProperties + @Configuration注解组合的方式,使用如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
/**
* 系统配置
*
* @author 恒宇少年
*/
@Configuration
@ConfigurationProperties(prefix = SYSTEM_CONFIG_PREFIX)
@Data
public class SystemConfig {
/**
* 系统配置前缀
*/
public static final String SYSTEM_CONFIG_PREFIX = "system.config";

private String appId;
private String appSecret;
}

注意事项:配置参数与JavaBean属性之间的绑定是通过调用JavaBean属性的Setter方法来赋值的,所以我们需要提供对应属性字段的Setter方法。

由于@Configuration注解被@Component修饰,所以我们在使用时只需要注入SystemConfig配置绑定映射类即可,通过Getter方法来获取对应配置参数的值。

配置扫描路径方式绑定

如果你系统中需要创建的配置映射类较多,而且每一个类都需要交付给IOC容器进行托管,那么可以考虑使用@ConfigurationPropertiesScan + @ConfigurationProperties注解组合的方式,使用如下所示:

1
2
3
4
5
6
7
8
@SpringBootApplication
@ConfigurationPropertiesScan
public class ConfigureBindingAwayApplication {

public static void main(String[] args) {
SpringApplication.run(ConfigureBindingAwayApplication.class, args);
}
}

我们首先需要在XxxApplication应用程序启动类上添加@ConfigurationPropertiesScan注解,表示我们需要使用自动扫描的方式来注册配置映射类,注解配置参数如下所示:

  • value:配置扫描的基础package,与basePackages作用一致,通过数组的形式来接收配置。
  • basePackages:配置扫描的基础package
  • basePackageClasses:配置基础扫描类,会将每一个扫描类所处于的package作为扫描基础package

当我们在使用@ConfigurationPropertiesScan注解时,如果不进行自定义扫描路径,默认使用SpringBoot应用程序扫描的packages

使用这种方式我们配置映射类就不再需要添加@Configuration注解了,这是因为我们在使用@ConfigurationPropertiesScan注解时,会通过@Import方式来引用配置映射类的注册实现,详见:org.springframework.boot.context.properties.ConfigurationPropertiesScanRegistrar#registerBeanDefinitions,配置映射类如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/**
* 系统配置
*
* @author 恒宇少年
*/
@ConfigurationProperties(prefix = SYSTEM_CONFIG_PREFIX)
@Data
public class SystemConfig {
/**
* 系统配置前缀
*/
public static final String SYSTEM_CONFIG_PREFIX = "system.config";

private String appId;
private String appSecret;
}

构造函数方式绑定

在上面的两种方式都是通过Setter方法来进行映射字段的赋值,而构造函数绑定方式是通过构造函数来进行赋值的,我们只需要在配置映射类上添加@ConstructorBinding注解并提供对应的构造函数即可,使用方式如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
/**
* 系统配置
*
* @author 恒宇少年
*/
@ConfigurationProperties(prefix = SYSTEM_CONFIG_PREFIX)
@ConstructorBinding
@Getter
public class SystemConfig {
/**
* 系统配置前缀
*/
public static final String SYSTEM_CONFIG_PREFIX = "system.config";

public SystemConfig(String appId, String appSecret) {
this.appId = appId;
this.appSecret = appSecret;
}

private String appId;
private String appSecret;
}

在之前我也写过一篇关于构造函数映射配置参数的问题,详情访问:@ConstructorBinding注解的使用

第三方类绑定

如果我们需要将配置参数映射绑定到第三方依赖内提供的JavaBean,我们该使用什么方式呢?由于接收参数的类并不是我们自己编写的,所以没有办法对.class文件源码进行修改。

这时我们可以将第三方提供的JavaBean交给IOC容器托管,然后结合@ConfigurationProperties注解来映射绑定配置参数,使用方式如下所示:

1
2
3
4
5
@Bean
@ConfigurationProperties(prefix = SYSTEM_CONFIG_PREFIX)
public SystemConfig systemConfig() {
return new SystemConfig();
}

这种方式也需要第三方提供的JavaBean有映射字段的Setter方法,否则无法进行赋值。

我们知道通过@Bean注解修饰的方法,会将方法的返回值加入到IOC容器内,那我们在使用配置时,直接注入配置映射类就可以了。

总结

上面这几种配置绑定方式都遵循OOP实现,当然如果你只需要获取一个配置参数,使用@Value也是一个好的选择,没有更好,只有更合适,根据每一种绑定方式的特点合理的选择一个合适业务的方式。

SpringBoot2.x基础篇:使用YAML代替Properties的对应配置

YAML是一种用于指定层次结构配置数据的便捷格式,SpringBoot内部通过集成SnakeYAML来支持解析,那我们如果来使用YAML格式来代替Properties,我们需要了解每一种Properties对应YAML的配置代替方式。

推荐阅读

普通配置

普通的方式比较简单直接,不存在数组集合子类等相关配置,我们通过Properties方式编写了如下的配置内容:

1
2
3
system.config.max-value=100
system.config.min-value=10
system.config.location=classpath:/configs

那这种方式对应的YAML配置是什么样子的呢?

如下所示:

1
2
3
4
5
system:
config:
min-value: 10
max-value: 100
location: classpath:/configs

这两种方式对比之下,YAML层次感鲜明,更直观的查看配置信息,而Properties这种方式配置前缀相对来说是冗余的,如果配置前缀过长,每一行的配置内容则会更长。

List配置

如果你需要添加List/Set/Array类型的配置信息,使用Properties方式编写如下所示:

1
2
3
system.config.ports[0]=8080
system.config.ports[1]=8081
system.config.ports[2]=8082

注意事项:配置的索引从0开始。

对应上面配置的YAML实现如下所示:

1
2
3
4
5
6
system:
config:
ports:
- 8080
- 8081
- 8082

无论是Properties还是YAML格式,这种List的配置内容都可以通过如下的方式获取:

1
2
3
4
5
6
@Configuration
@ConfigurationProperties(prefix = "system.config")
@Data
public class LoadListConfig {
private List<String> ports;
}

List内实体配置

如果你的List内不是基本数据类型,而是一个实体类,使用Properties的配置方式如下所示:

1
2
3
4
system.users[0].username=admin
system.users[0].email=yuqiyu@vip.qq.com
system.users[1].username=hengboy
system.users[1].email=jnyuqy@gmail.com

其实跟上面的List配置差不多,不过如果你需要配置每一个索引内字段的值,就要一一指定配置值。

对应上面的YAML实现如下所示:

1
2
3
4
5
6
system:
users:
- username: admin
email: yuqiyu@vip.qq.com
- username: hengboy
email: jnyuqy@gmail.com

每一个 - 其实代表集合内的一个元素。

获取List实体配置时我们可以通过如下的方式:

1
2
3
4
5
6
7
8
9
10
11
12
13
@Data
@Configuration
@ConfigurationProperties(prefix = "system")
public class LoadSystemUserConfig {
private List<User> users;

@Getter
@Setter
public static class User {
private String username;
private String email;
}
}

YAML缺点

一种方案的诞生是为了解决相应的问题,虽然说存在既有道理,但是每一种方案也不是完美的都有自身的缺点。

下面简单说说YAML的缺点:

  • 配置时缩进要特别注意,如果存在空格缩进对应不齐就会出现问题
  • SpringBoot内无法通过@PropertySource注解加载YAML文件。

SpringBoot2.x基础篇:配置文件中占位符的使用

概念

占位符是一种灵活的配置方式,可以让我们很灵活的使用配置参数,@Value注解的配置也是占位符的一种体现方式,这种方式可以从Environment内获取对应的配置值

推荐阅读

配置方式

application.yml/properties配置文件内可以直接使用占位符来进行配置的相互引用,如下所示:

1
2
3
4
5
system:
name: ${spring.application.name}
spring:
application:
name: project-sample

在上面的配置中,name配置直接引用了spring.application.name的配置值,这样我们在系统中通过@Value("${name}")或者通过@ConfigurationProperties方式使用时,得到的值都为project-sample

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// @Value方式
@Value("${system.name}")
private String name;

// @ConfigurationProperties方式
@Configuration
@ConfigurationProperties(prefix = "system")
static class LoadConfig {
private String name;

public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}
}

这样方式极大地减少了相同的配置出现,让我们在配置文件中也可以实现类似于常量的定义。

使用默认值

当我们使用@Value注解来注入配置参数时,如果所引入的配置为NULL,启动项目时会抛出异常,项目无法正常启动,所以我们有必要添加一个默认值,如下所示:

1
2
3
4
5
system:
name: ${spring.application.name:default}
#spring:
# application:
# name: project-sample

在上面配置中把spring.application.name注释掉,当我们使用${spring.application.name}占位符时其实并未引用到有效的值,通过${xxx:defaultValue}的形式可以配置默认值,当占位符所引用的配置为NULL时,将会使用默认值(默认值的类型要对配置匹配)。

也可以通过@Value("${system.name:default}")这种方式配置默认值,不建议使用这种方式,默认值有变动时,我们还要一个一个修改,太麻烦了,不要给自己找事干…

当然对于配置的注入还是推荐使用@ConfigurationProperties,完全遵循OOP设计方式,在应用程序启动时进行赋值,就算是引用的配置为NULL没有默认值,也不会出现启动异常的问题。

“短”命令行参数

如果你对命令行参数不熟悉,可以访问 SpringBoot2.x基础篇:灵活的使用外部化配置信息 学习。

在实际部署应用程序时,有很多的配置是动态的,命令行参数是一个不错的方式,不过SpringBoot所提供的配置参数名称都比较长,对此我们完全可以利用占位符配置方式实现自定义。

占位符是从Environment内读取对应的配置值,而命令行参数在应用程序启动时会被一并加入到Environment中,因此也就实现了占位符动态配置,其实这个“短”的含义,是你定义的新的配置名称比较短而已。

假设我们的端口号需要动态指定,配置文件中可以通过如下的方式配置:

1
2
server:
port: ${port:8080}

port是我们定义的“短”占位符,在应用程序启动时并未指定则使用默认值8080

1
java -jar project-sample.jar --port=9090

通过--port=9090命令行参数,应用程序启动时端口号就变为了9090

SpringBoot2.x基础篇:配置文件的加载顺序以及优先级覆盖

SpringBoot约定了配置文件,默认为application.properties,通过该文件可以修改很多默认的配置,当然我们还可以在该配置文件内添加自定义的配置,该文件通过key=value的形式进行配置。

推荐阅读

疑惑配置提示?

当我们使用开发工具来配置时,就会出现相应的提示,这要完全要归功于spring-configuration-metadata.json配置元数据文件,该文件内记录了配置的名称类型归属类等信息,如果配置类型为枚举还可以实现选择性配置

SpringBoot提供了一个依赖,它的主要任务就是自动生成配置元数据,该依赖的名称为spring-boot-configuration-processor,在打包时会在META-INF目录生成一个名为spring-configuration-metadata.json的文件。

配置方式

虽然默认使用properties格式的配置文件,不过这种方式会导致配置的部分前缀冗余,可阅读性稍差,SpringBoot内部还支持使用yaml方式的配置文件,只需要在src/main/resources目录下创建一个名为application.yml文件即可,使用配置时同样也有提供功能。

项目内可以同时存在application.propertiesapplication.yml两个文件,经过测试发现,properties优先级会高一些,相同名称的配置,会将yml内的配置覆盖掉。

指定配置文件

如果你的应用程序配置文件的名称不是application,你想要进行自定义,可以通过--spring.config.name命令行参数进行指定,如下所示:

1
java -jar project-sample.jar --spring.config.name=custome

注意事项:我们只需要指定配置文件的名称即可,可以使用propertiesyaml文件格式,上面的配置会加载src/main/resources/custome.ymlsrc/main/resources/custome.properties

通过--spring.config.name仅仅是修改了配置文件的名称,那如果是修改配置文件所处的目录位置,我们需要怎么做呢?

SpringBoot已经给我们准备好了,通过--spring.config.location参数就可以指定配置文件的位置,如下所示:

1
java -jar project-sample.jar --spring.config.location=classpath:/configs/custome.yml

如果一个配置文件无法满足你的需求,那你看看下面这个方式:

1
java -jar project-sample.jar --spring.config.location=classpath:/configs/custome.yml,classpath:/configs/default.properties

注意事项:支持通过命令行参数的方式指定多个配置文件,使用英文半角 , 隔开即可。

如果你通过spring.config.location指定的不是一个文件而是一个目录,在路径最后务必添加一个”/“结束,然后结合spring.config.name进行组合配置文件,组合示例如下:

1
2
3
4
5
# 加载/configs/application.properties 或 /configs/application.yml(默认文件名)
java -jar project-sample.jar --spring.config.location=classpath:/configs/

# 加载/configs/custome.properties 或 /configs/custome.yml
java -jar project-sample.jar --spring.config.location=classpath:/configs/ --spring.config.name=custome

注意事项:spring.config.name该配置参数默认值为application,所以如果只是指定了spring.config.location并为目录形式,上面示例中会自动将spring.config.name追加到目录路径后,如果指定的spring.config.location并非是一个目录,这里会忽略spring.config.name的值。

加载顺序

SpringBoot应用程序在启动时会遵循下面的顺序进行加载配置文件:

  1. 类路径下的配置文件
  2. 类路径内config子目录的配置文件
  3. 当前项目根目录下的配置文件
  4. 当前项目根目录下config子目录的配置文件

示例项目配置文件存放结构如下所示:

1
2
3
4
5
6
7
8
. project-sample
├── config
│ ├── application.yml (4)
│ └── src/main/resources
| │ ├── application.yml (1)
| │ └── config
| | │ ├── application.yml (2)
├── application.yml (3)

启动时加载配置文件顺序:1 > 2 > 3 > 4

src/main/resources下的配置文件在项目编译时,会放在target/classes下。

优先级覆盖

SpringBoot配置文件存在一个特性,优先级较高的配置加载顺序比较靠后相同名称的配置优先级较高的会覆盖优先级较低的内容。

为了更好地解释这一点,我们根据对应的加载顺序分别创建一个application.yml配置文件,来验证根据优先级的不同是否存在覆盖问题,如下图所示:

在上面四个配置文件中都有一个名为name的配置,而红色字体标注的内容就是每个配置文件name的配置内容,下面我们来启动项目测试下输出内容。

运行测试

在测试之前我们让启动类实现CommandLineRunner接口,如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@SpringBootApplication
public class LoadOrderOfConfigFilesApplication implements CommandLineRunner {

public static void main(String[] args) {
SpringApplication.run(LoadOrderOfConfigFilesApplication.class, args);
}

@Value("${name}")
private String name;

@Override
public void run(String... args) throws Exception {
System.out.println("配置名称:" + name);
}
}

项目启动后通过run方法进行打印${name}配置的内容。

测试一:顺序覆盖

保留上面四个对应加载顺序的配置文件,启动项目,控制台输出内容:

1
配置名称:project/config

期望与实际输出是符合的,项目根下的config目录是最后加载的,所以它的优先级相对其他三个来说是最高的,覆盖顺序为:4 > 3 > 2 > 1

测试二:跨顺序覆盖

上一个测试点我们对每一个加载顺序都对应添加了一个配置文件,那如果我们只有两个project/configclasses/config两个目录的配置文件,是否按照优先级进行覆盖呢?

删除另外两个,只保留project/configclasses/config两个位置的配置文件,启动项目控制台输出如下所示:

1
配置名称:project/config

同样是输出了优先级最高的project/config配置文件的内容,覆盖顺序为:4 > 1

测试点:单顺序加载

平时在项目开发中一般都是将application.yml配置文件放在src/main/resources目录下,然而根据上面的加载顺序来看,我们可以将配置文件放置在任意一处,启动时都会进行加载。

仅保留classes/config位置的配置文件,启动项目控制台输出内容如下所示:

1
配置名称:classes/config

IDEASpringBoot的支持真的很强大, classes/config下的配置文件同样提供了关键字提醒功能。

总结

了解配置文件的加载顺序,才能得心应手的进行配置覆盖,完全控制在不同环境下使用不同的配置内容,要记住classes/application.yml优先级最低,project/config/application.yml优先级最高。

SpringBoot2.x基础篇:探索配置文件中随机数的实现方式

随机数的使用你是不是经常用到?我们在进行运行SpringBoot单元测试时一般不会指定应用程序启动时的端口号,可以在application.properties文件内配置server.port的值为${random.int(10000)},代表了随机使用0~10000的端口号。

既然这种方式使用这么方便,那你知道${random.int}是通过什么方式实现的吗?

推荐阅读

概述

配置文件方式

在我们分析源码之前,我们先来看看${random.xxx}具体提供了哪几种的随机配置。

int随机数

使用${random.int}方式配置,结果从int的最大值、最小值中间产生,int的最小值为-2147483648,最大值为2147483647,配置如下所示:

1
2
server:
port: ${random.int}

int范围随机数

使用${random.int(10000)}方式配置,这种方式我们可以指定随机数的最大值,当然不能超过2147483647,配置如下所示:

1
2
server:
port: ${random.int(10000)}

注意事项:${random.int(10000)}随机数的值将会在0~10000之间产生,配置的最大值必须为正整数

如果需要指定随机数的最小值,可以使用${random.int[100,200]}方式配置,这样只会从100~200之间产生随机数(包括最小值,不包括最大值)。

long随机数

使用${random.long}方式配置,结果会从long的最大值、最小值中间产生,long的最小值为-9223372036854775808,最大值为9223372036854775807,配置方式如下所示:

1
2
config:
longValue: ${random.long}

long范围随机数

使用${random.long(10000)}方式配置,我们可以指定0~9223372036854775807之间的任意数值作为随机的最大上限,配置方式如下所示:

1
2
config:
maxLongValue: ${random.long(102400)}

如果需要指定最小值,可以使用${random.long[1024,2048]}方式配置,这样只会从1024~2048中产生随机数(包括最小值,不包括最大值)。

uuid随机数

uuid因为它的唯一性,应该是我们平时开发中比较常用到的。

SpringBoot也为我们考虑到了这一点,我们只需要使用${random.uuid}就可以获得一个随机的uuid字符串,配置方式如下所示:

1
2
config:
uuid: ${random.uuid}

@Value方式

如果在我们在编码中需要用到随机数的生成,${random}是支持注入使用的,主要还是因为它的实现继承自PropertySource

我们可以在Spring IOC所管理的类内直接使用@Value注解进行注入使用,如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/**
* 随机生成uuid字符串
*/
@Value("${random.uuid}")
private String uuid;
/**
* 随机生成0~1000的正整数
*/
@Value("${random.int(1000)}")
private int maxInt;
/**
* 随机生成0~102400的long类型数值
*/
@Value("${random.long(102400)}")
private long maxLong;

源码解析

我们之所以可以这么方便的使用随机数,都归功于SpringBoot为我们提供了一个名为RandomValuePropertySourcePropertySource实现类,该实现类位于org.springframework.boot.env包内,该类部分源码如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
/**
* {@link PropertySource} that returns a random value for any property that starts with
* {@literal "random."}. Where the "unqualified property name" is the portion of the
* requested property name beyond the "random." prefix, this {@link PropertySource}
* ...
*/
public class RandomValuePropertySource extends PropertySource<Random> {

private static final String PREFIX = "random.";

private static final Log logger = LogFactory.getLog(RandomValuePropertySource.class);

@Override
public Object getProperty(String name) {
// 仅处理random.开头的配置
if (!name.startsWith(PREFIX)) {
return null;
}
if (logger.isTraceEnabled()) {
logger.trace("Generating random property for '" + name + "'");
}
// 获取数据数,将random.后的内容作为类型参数传递到getRandomValue方法
return getRandomValue(name.substring(PREFIX.length()));
}

private Object getRandomValue(String type) {
// 处理random.int类型的随机数
if (type.equals("int")) {
return getSource().nextInt();
}
// 处理random.long类型的随机数
if (type.equals("long")) {
return getSource().nextLong();
}
// 处理random.int(100)类型的随机数
String range = getRange(type, "int");
if (range != null) {
// 生成有范围的int类型随机数
return getNextIntInRange(range);
}
// 处理random.long(1024)类型的随机数
range = getRange(type, "long");
if (range != null) {
// 生成有范围的long类型随机数
return getNextLongInRange(range);
}
// 处理random.uuid类型的随机数
if (type.equals("uuid")) {
// 生成随机的uuid返回
return UUID.randomUUID().toString();
}
// 默认返回随机字节
return getRandomBytes();
}

private String getRange(String type, String prefix) {
if (type.startsWith(prefix)) {
int startIndex = prefix.length() + 1;
if (type.length() > startIndex) {
return type.substring(startIndex, type.length() - 1);
}
}
return null;
}

private int getNextIntInRange(String range) {
String[] tokens = StringUtils.commaDelimitedListToStringArray(range);
int start = Integer.parseInt(tokens[0]);
if (tokens.length == 1) {
return getSource().nextInt(start);
}
return start + getSource().nextInt(Integer.parseInt(tokens[1]) - start);
}

private long getNextLongInRange(String range) {
String[] tokens = StringUtils.commaDelimitedListToStringArray(range);
if (tokens.length == 1) {
return Math.abs(getSource().nextLong() % Long.parseLong(tokens[0]));
}
long lowerBound = Long.parseLong(tokens[0]);
long upperBound = Long.parseLong(tokens[1]) - lowerBound;
return lowerBound + Math.abs(getSource().nextLong() % upperBound);
}
}

当我们使用${random.xxx}这种方式获取随机数时,无论是配置文件方式还是@Value方式都会通过org.springframework.boot.env.RandomValuePropertySource#getProperty方法来获取对应类型的随机数。

注意事项:RandomValuePropertySource在继承PropertySource时泛型类型为Randomjava.util.Random类内包含了全部的随机生成逻辑,该类由java提供,有兴趣可以研究下源码。

总结

SpringBoot内的配置都是通过ConfigurablePropertyResolver属性配置解析器来获取的,而该类的实例化在AbstractEnvironment内,我们通过AbstractEnvironment#getProperty(java.lang.String)方法可以获取由多个PropertySource实现类提供的属性配置。

SpringBoot2.x基础篇:灵活的使用外部化配置信息

SpringBoot提供了内部配置application.yml文件的方式来进行全局配置,还支持使用profiles来激活不同环境下使用不同的配置文件,而这种方式毕竟是已经打包完成了,因此存在一定的局限性,像数据库特殊敏感配置也可能存在泄露的风险,如何解决这种问题呢?我们来看看本章要讲到的外部配置的方式吧!!!

SpringBoot2.x基础篇:应用程序在启动时访问启动项参数

SpringBoot应用程序在启动时,我们可以传递自定义的参数来进行动态控制逻辑,比如我们使用--debug启动参数时就会使用debug启动应用程序,在控制台打印一些调试日志信息。

推荐阅读

什么是启动项参数?

启动项参数的格式一般是--开头的,如:java -jar service.jar --debug --skip,启动时我们就可以获取[debug,skip]两个启动项参数。

SpringBoot 内部提供了一个接口org.springframework.boot.ApplicationArguments来接收应用程序在启动时所传递的选项参数(Option Args),源码如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
public interface ApplicationArguments {

/**
* 返回未处理的原始参数列表
* @return the arguments
*/
String[] getSourceArgs();

/**
* 返回所有选项参数的名称
* For example, if the arguments were
* "--foo=bar --debug" would return the values {@code ["foo", "debug"]}.
* @return the option names or an empty set
*/
Set<String> getOptionNames();

/**
* 根据选项参数名称判断是否在启动时传递
* option with the given name.
* @param name the name to check
* @return {@code true} if the arguments contain an option with the given name
*/
boolean containsOption(String name);

/**
* 返回与具有给定名称的arguments选项关联的值的集合。
* <ul>
* <li>if the option is present and has no argument (e.g.: "--foo"), return an empty
* collection ({@code []})</li>
* <li>if the option is present and has a single value (e.g. "--foo=bar"), return a
* collection having one element ({@code ["bar"]})</li>
* <li>if the option is present and has multiple values (e.g. "--foo=bar --foo=baz"),
* return a collection having elements for each value ({@code ["bar", "baz"]})</li>
* <li>if the option is not present, return {@code null}</li>
* </ul>
* @param name the name of the option
* @return a list of option values for the given name
*/
List<String> getOptionValues(String name);

/**
* 返回分析的非选项参数的集合。
* @return the non-option arguments or an empty list
*/
List<String> getNonOptionArgs();
}

该接口有一个默认的实现DefaultApplicationArguments,它实现了ApplicationArguments接口的全部定义方法。

DefaultApplicationArguments类在org.springframework.boot.SpringApplication#run(java.lang.String...)方法内通过new进行实例化,该对象实例主要用于启动时的相关配置。

而在启动过程中的org.springframework.boot.SpringApplication#prepareContext方法内通过ConfigurableListableBeanFactory进行注册到IOC容器,并且把springApplicationArguments作为唯一名称。

获取启动项参数

上面我们说道,在应用启动时会将ApplicationArguments接口的实现类实例注册到IOC容器,所以我们可以使用注入ApplicationArguments接口的形式来获取启动项参数,如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
/**
* 加载启动项参数
*
* @author 恒宇少年
*/
@Component
public class LoadArguments {
/**
* 构造函数注入{@link ApplicationArguments}
*
* @param applicationArguments
*/
@Autowired
public LoadArguments(ApplicationArguments applicationArguments) {
// 判断是否存在名为skip的启动项参数
boolean isHaveSkip = applicationArguments.containsOption("skip");
System.out.println("skip:" + isHaveSkip);
// 遍历输出全部的非启动项参数
List<String> arguments = applicationArguments.getNonOptionArgs();
for (int i = 0; i < arguments.size(); i++) {
System.out.println("非启动项参数:" + arguments.get(i));
}
}
}

我们把项目通过mvn package命令进行打包后,使用如下命令启动:

1
java -jar spring-boot-basic-accessing-application-arguments-0.0.1-SNAPSHOT.jar --skip noway

当我们启动后控制台会输出如下内容:

1
2
3
4
...
skip:true
非启动项参数:noway
...

其中--skip为启动项参数,而后面携带的noway其实是不属于skip启动参数,如果我们使用--skip=noway作为启动参数时,调用ApplicationArguments#getOptionValues("skip")方法获取到的值则是noway

ApplicationRunner

除了通过注入ApplicationArguments的方式获取启动参数外,通过实现ApplicationRunner接口也可以获取ApplicationArguments对象实例,使用方法如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
/**
* {@link ApplicationRunner} 实现类
*
* @author 恒宇少年
*/
@Component
public class ApplicationRunnerSupport implements ApplicationRunner {
@Override
public void run(ApplicationArguments args) throws Exception {
boolean isHaveSkip = args.containsOption("skip");
System.out.println("skip:" + isHaveSkip);
System.out.println(args.getOptionValues("skip"));
}
}

注意事项:实现ApplicationRunner接口的类需要通过@Component标注,通过注解方式注册到IOC容器。

敲黑板,划重点

我们可以通过注入ApplicationRunner这两种方法来获取ApplicationArguments对象,那你知道这两种方法的执行先后顺序吗?带着这个疑问可以动手实验下。

代码示例

如果您喜欢本篇文章请为源码仓库点个Star,谢谢!!!
本篇文章示例源码可以通过以下途径获取,目录为spring-boot-basic-accessing-application-arguments

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×