Spring Security3.0.2.1版本
前言:
通过实践而发现真理,又通过实践而证实真理和发展真理。从感性认识而能动地发展到理性认识,又从理性认识而能动地指导革命实践,改造主观世界和客观世界。实践、认识、再实践、再认识,这种形式,循环往复以至无穷,而实践和认识之每一循环的内容,都比较地进到了高一级的程度。
温故:
Security配置模板
@Configuration //必备
@EnableWebSecurity //必备
public class SpringSecurityConfig {
}
第一点:基于Security filter(拦截器)的登录认证——Login方法无法实现
第二点:基于UserDetailsService方法进行验证登录——
两个共同点:
第一点:实例化InMemoryUserDetailsManager这个类,并调用对象方法createUser
第二点:调用User类,中的withDefaultPasswordEncoder,username,password,roles,build方法
第三点(基于第二点的实践总结):无法通过添加参数去做到登录
知新:
实践固然重要,但是这不代表理论没有用!
步子迈的太大,容易扯着蛋,很显然作者已经扯到了蛋,想要直接通过官方文档去完成自定义用户登录是十分愚蠢的,需要按部就班的向前走
正片:
Spring Security:是一个Java框架,用于保护应用程序的安全性。它提供了一套全面的安全解决方案,包括身份验证、授权、防止攻击等功能
目的:我们需要使用Spring Security完成一个基于数据库的身份验证功能
回到最开始的这段代码
@EnableWebSecurity
@Configuration
public class DefaultSecurityConfig {
@Bean
@ConditionalOnMissingBean(UserDetailsService.class)
InMemoryUserDetailsManager inMemoryUserDetailsManager() {
String generatedPassword = // ...;
return new InMemoryUserDetailsManager(User.withUsername("user")
.password(generatedPassword).roles("ROLE_USER").build());
}
@Bean
@ConditionalOnMissingBean(AuthenticationEventPublisher.class)
DefaultAuthenticationEventPublisher defaultAuthenticationEventPublisher(ApplicationEventPublisher delegate) {
return new DefaultAuthenticationEventPublisher(delegate);
}
}
这两段代码提供了登录需要用的账号密码
猜想:通过修改实参去验证
验证:我们通过修改User.password的实参,判断是否可行
实践代码一
@Configuration
@EnableWebSecurity
public class SpringSecurityConfig {
@Bean
@ConditionalOnMissingBean(UserDetailsService.class)
InMemoryUserDetailsManager inMemoryUserDetailsManager() {
String generatedPassword = "123456789";
return new InMemoryUserDetailsManager(User.withUsername("user")
.password(generatedPassword).roles("ROLE_USER").build());
}
}
实践结果:登录失败
验证二:修改USer.Username实参
实践demo
@Configuration
@EnableWebSecurity
public class SpringSecurityConfig {
@Bean
@ConditionalOnMissingBean(UserDetailsService.class)
InMemoryUserDetailsManager inMemoryUserDetailsManager() {
return new InMemoryUserDetailsManager(User.withUsername("admit")
.roles("ROLE_USER").build());
}
}
实践结果:失败
即无通过修改 new new InMemoryUserDetailsManager(User.withUsername("admit")
.roles("ROLE_USER").build());完成登录验证
猜想这段代码其实就是我们需要的内容
@EnableWebSecurity
@Configuration
public class DefaultSecurityConfig {
@Bean
@ConditionalOnMissingBean(UserDetailsService.class)
InMemoryUserDetailsManager inMemoryUserDetailsManager() {
String generatedPassword = // ...;
return new InMemoryUserDetailsManager(User.withUsername("user")
.password(generatedPassword).roles("ROLE_USER").build());
}
}
密码会随机生成,并打印在控制台
随着实践的增加,我们又修改了实践过程
先找到基础架构,再去找到用户名和密码
我们使用的是表单
请求进入到了SecurityFilterChain,进入到了第一层验证——账号密码验证
通过HttpServletRequest读取到用户输入的表单信息
我们获取到了核心的账号密码如何获取,通过HttpServletRequest,其余的都是看不懂的文字
又看了一遍
《这一节更多的是对架构的抽象描述,而没有过多的讨论它如何应用于具体的流程》
天哪!怪不得看得这么怪
在这里我们找到了《这些章节集中讨论了你可能想要的具体的认证方式,并回到架构部分来描述具体的流程如何运作》
点击第一个!
又回到了这点
《Spring Security 为使用用户名和密码进行验证提供了全面的支持。》
进行账号密码登陆前需要获得用户输入的账号密码——后端通过HttpServletRequest获取
通过loginPage,绑定前端表单
到这里,我彻底发现了问题,那就是这么多步骤看下来——结果是为了获取前端输入内容,而不是将user和password修改为我们自己的内容
虽然这个对后续连接前端有用,当前阶段我们需要的是修改user和password内容