Spring Security

⒈添加Spring Boot Security Starter依赖

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-security</artifactId>
        </dependency>

　　当Spring Boot的自动装配检测到Spring Secutity出现在了类路径中，将会初始化一些基本的安全配置。

　　此时启动应用，应用将会弹出一个HTTP Basic认证对话框并提示你进行认证，用户名为user，密码是随机生成的。它会被写入到应用的日志文件中。输入了正确的用户名和密码后，你就有权限访问应用了。

　　Spring Security自动装配提供了以下安全特性：

• 所有的HTTP请求路径都需要认证【这包括你的首页】
• 不需要特定的角色和权限
• 没有登录页面
• 认证过程是通过HTTP Basic认证对话框实现的
• 系统只有一个用户，用户名为user。

⒉配置Spring Security

　　基于XML来配置Spring Security不在本文的讨论之内，建议移步其他文章。

　　基于Java来配置Spring Security首先你需要继承Spring 提供的适配器

package cn.coreqi.config;

import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
}

　　此时，Spring的上下文容器中注册了我们自己的Security配置，Spring Security发生了改变，现在不再是提示HTTP Basic认证的对话框，而是会展现一个登录表单。

3.配置Spring Security用户存储

　　Spring Security为配置用户存储提供了多个可选解决方案，包括：

• 基于内存的用户存储
• 基于JDBC的用户存储
• 以LDAP作为后端的用户存储
• 自定义用户详情服务

　　不管使用哪种用户存储，都可以通过 WebSecurityConfigurerAdapter 基础配置类中定义的configure()方法来进行配置，首先我们需要重写configure()方法。

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        super.configure(auth);
    }

　　1.基于内存的用户存储

　　Spring Security支持将用户信心存储在内存之中，假设我们的应用只有数量有限的几个用户，而且这些用户几乎不会发生变化，在这种情况下，将这些用户定义在内存中是非常理想的实现方式。

　　

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.inMemoryAuthentication()
                .withUser("fanqi")
                    .password("fanqisoft")
                    .authorities("ROLE_ADMIN","ROLE_USER")
                .and()
                .withUser("zhangsan")
                    .password("123456")
                    .authorities("ROLE_USER");
    }

　　对于测试和简单的应用来讲，基于内存的用户存储是很有用的，但是这种方式不能很方便的编辑用户。如果需要新增、移除或变更用户，那么你要对代码做出必要的修改，然后重新构建和部署应用。

　　2.基于JDBC的用户存储

　　用户信息通常会在关系型数据库中进行维护，基于JDBC的用户存储方案会更加合理一些。

    @Autowired
    private DataSource dataSource;

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.jdbcAuthentication()
                .dataSource(dataSource);
    }

　　在这里的configure()实现中，调用了AuthenticationManagerBuilder 的 jdbcAuthentication()方法。我们还必须要设置一个DataSource，这样它才能知道如何访问数据库。

　　重写默认的用户查询功能

　　虽然短短的两句话就足以让Spring Security使用JDBC进行用户存储，但它同样也对我们的数据库模式有了一定的要求。

　　让我们查看一下Spring Security JDBC用户存储下默认的实现【org.springframework.security.core.userdetails.jdbc.JdbcDaoImpl】，节选部分代码、

    public static final String DEF_USERS_BY_USERNAME_QUERY = "select username,password,enabled from users where username = ?";
    public static final String DEF_AUTHORITIES_BY_USERNAME_QUERY = "select username,authority from authorities where username = ?";
    public static final String DEF_GROUP_AUTHORITIES_BY_USERNAME_QUERY = "select g.id, g.group_name, ga.authority from groups g, group_members gm, group_authorities ga where gm.username = ? and g.id = ga.group_id and g.id = gm.group_id";

　　在第一个查询中，我们获取了用户的用户名、密码以及是否启用的信息，用来进行用户认证。

　　在第二个查询中，我们查找了所授予用户的权限，用来进行鉴权。

　　在第三个查询中，我们查找了用户作为群组的成员所授予的权限。

　　如果你能够在数据库中定义和填充满足这些查询的表，那么基本上就不需要再做什么额外的事情了。但是，也有可能你的数据库与上述的不一致，那么你会希望在查询上有更多的控制权。

    @Autowired
    private DataSource dataSource;

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.jdbcAuthentication()
                .dataSource(dataSource)
                .usersByUsernameQuery(
                        "select username,password,enabled from t_user where username = ?"
                )
                .authoritiesByUsernameQuery(
                        "select username,authority from t_authoritie where username = ?"
                )
                .groupAuthoritiesByUsername(
                        "select g.id, g.group_name, ga.authority from groups g, group_members gm, group_authorities ga where gm.username = ? and g.id = ga.group_id and g.id = gm.group_id"
                );
    }

　　将默认的SQL查询替换为自定义的设计时，很重要的一点就是要遵循查询的基本协议。所有查询都将用户名作为唯一的参数。认证查询会选取用户名、密码以及启用状态信息。权限查询会选取0行或者多行包含该用户名及其权限信息的数据。群组权限查询会选取0行或多行数据，每行数据中都会包含群组ID、群组名称以及权限。

　　指定密码转码器【现在还有人用明文保存密码？】

　　通过passwordEncoder()方法指定一个密码转码器（encoder）

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.jdbcAuthentication()
                .dataSource(dataSource)
                .passwordEncoder(PasswordEncoderFactories.createDelegatingPasswordEncoder());
    }

　　passwordEncoder()方法可以接收Spring Security中passwordEncoder接口的任意实现。

　　以下为Spring Security内置的常用passwordEncoder 接口实现。

　　

BCryptPasswordEncoder	使用bcrypt强哈希加密
NoOpPasswordEncoder	不进行任何转码
Pbkdf2PasswordEncoder	使用PBKDF2加密
SCryptPasswordEncoder	使用scrypt哈希加密
StandardPasswordEncoder	使用SHA-256哈希加密

 　　如果内置的实现无法满足需求时，你甚至可以提供自定义的实现。PasswordEncoder接口非常简单：

public interface PasswordEncoder {

    String encode(CharSequence rawPassword);

    boolean matches(CharSequence rawPassword, String encodedPassword);

    default boolean upgradeEncoding(String encodedPassword) {
        return false;
    }

}

　　无论使用哪种密码转码器，重要的是要理解数据库中的密码永远不会被解码。相反，用户在登录时输入的密码使用相同的算法进行编码，然后将其与数据库中编码的密码进行比较。比较是在 PasswordEncoder 的 matches() 方法中进行的。

　　3.以LDAP作为后端的用户存储

　　LDAP（Lightweight Directory Access Protocol，轻量级目录访问协议），为了配置Spring Security使用基于LDAP认证，我们可以使用ldapAuthentication() 方法。这个方法在功能上与 jdbcAuthentication() 类似。

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.ldapAuthentication()
                .userSearchFilter("(uid={0})")
                .groupSearchFilter("member={0}");
    }

　　userSearchFilter() 和 groupSearchFilter() 方法用来为基础 LDAP 查询提供过滤条件，它们分别用于搜索用户和组。默认情况下，对于用户和组的基础查询都是空的，也就是表明搜索会在LDAP 层次结构的根目录进行搜索。但是我们可以通过指定查询基础来改变这个默认行为：

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.ldapAuthentication()
                .userSearchBase("ou=people")
                .userSearchFilter("(uid={0})")
                .groupSearchBase("ou=groups")
                .groupSearchFilter("member={0}");
    }

　　userSearchBase() 方法为查找用户提供了基础查询。同样，groupSearchBase() 为查找组指定了基础查询。这个示例中我们声明用户应该在名为people的组织单元下搜索而不是从根开始，而组应该在名为groups的组织单元下搜索。

　　配置密码对比

　　基于 LDAP 身份认证的默认策略是进行绑定操作，直接通过 LDAP 服务器认证用户。另一种可选的方式是进行比对操作。这涉及将输入的密码发送到 LDAP 目录上，并要求服务器将这个密码与用户的密码进行比对。因为比对是在 LDAP 服务器中进行的，所以实际的密码是保密的。

　　如果你希望通过密码比对进行身份验证，可以通过声明 passwordCompare() 方法来实现：

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.ldapAuthentication()
                .userSearchBase("ou=people")
                .userSearchFilter("(uid={0})")
                .groupSearchBase("ou=groups")
                .groupSearchFilter("member={0}")
                .passwordCompare();
    }

　　默认情况下，在登录表单中提供的密码将与用户 LDAP 条目中的 userPassword 属性值进行比对。如果密码被保存在不同的属性中，可以使用 passwordAttribute() 方法来指定密码属性的名称：

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.ldapAuthentication()
                .userSearchBase("ou=people")
                .userSearchFilter("(uid={0})")
                .groupSearchBase("ou=groups")
                .groupSearchFilter("member={0}")
                .passwordCompare()
                .passwordEncoder(new BCryptPasswordEncoder())
                .passwordAttribute("passcode");
    }

　　在本例中，我们指定了要与给定密码进行比对的是“passcode”属性。另外，我们还可以指定密码转码器。在进行服务器端密码比对时，有一点非常好，那就是实际的密码在服务器端是私密的。但是进行尝试的密码还是需要通过网络线路传输到 LDAP 服务器上，这可能会被黑客所截获。为了防止这种情况，我们可以通过调用 passwordEncoder() 方法来指定加密策略。

　　在前面的示例中，密码使用 bcrypt 密码哈希函数加密，这需要 LDAP 服务器上的密码也使用 bcrypt 进行了加密。

　　引用远程 LDAP 服务器

　　到目前为止，我们忽略的一件事就是 LDAP 服务器和实际的数据在哪里？虽然已经将 Spring 配置为根据 LDAP 服务器进行身份验证，但是该服务器在哪里呢？

　　默认情况下，Spring Security 的 LDAP 身份验证将假设 LDAP 服务器监听本机的 33389端口。但是，如果 你的LDAP 服务器位于另一台机器上，那么可以使用 contextSource() 方法来配置这个地址：

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.ldapAuthentication()
                .userSearchBase("ou=people")
                .userSearchFilter("(uid={0})")
                .groupSearchBase("ou=groups")
                .groupSearchFilter("member={0}")
                .passwordCompare()
                .passwordEncoder(new BCryptPasswordEncoder())
                .passwordAttribute("passcode")
                .and()
                .contextSource()
                .url("ldap://tacocloud.com:389/dc=tacocloud,dc=com");
    }

　　contextSource() 方法会返回一个 ContextSourceBuilder对象，这个对象除了其他功能以外，还提供了 url() 方法来指定 LDAP 服务器的地址。

　　配置嵌入式的LDAP服务器

　　如果你没有 LDAP 服务器去做身份认证，Spring Security 还为我们提供了嵌入式的 LDAP 服务器。我们不再需要设置远程LDAP服务器的URL，只需通过 root() 方法指定嵌入式服务器的根前缀就可以了。

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.ldapAuthentication()
                .userSearchBase("ou=people")
                .userSearchFilter("(uid={0})")
                .groupSearchBase("ou=groups")
                .groupSearchFilter("member={0}")
                .passwordCompare()
                .passwordEncoder(new BCryptPasswordEncoder())
                .passwordAttribute("passcode")
                .and()
                .contextSource()
                .root("dc=tacocloud,dc=com");
    }　　

　　当 LDAP 服务器启动时，它会尝试从类路径下寻找 LDIF 文件来加载数据。LDIF（LDAP Data Interchange Format，LDAP 数据交换格式）是以文本文件展示 LDAP 数据的标准方式，每条记录可以有一行或多行，每行包含一个 name:value 配对信息，记录之间通过空行进行分隔。

　　如果你不想让 Spring 从整个类路径下寻找 LDIF 文件，那么可以通过调用 ldif() 方法来明确指定加载哪个 LDIF 文件：

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.ldapAuthentication()
                .userSearchBase("ou=people")
                .userSearchFilter("(uid={0})")
                .groupSearchBase("ou=groups")
                .groupSearchFilter("member={0}")
                .passwordCompare()
                .passwordEncoder(new BCryptPasswordEncoder())
                .passwordAttribute("passcode")
                .and()
                .contextSource()
                .root("dc=tacocloud,dc=com")
                .ldif("classpath:users.ldif");
    }

　　在这里，我们明确要求 LDAP 服务器从类路径根目录下的 users.ldif 文件中加载数据。如果你比较好奇，如下就是一个包含用户数据的LDIF 文件，我们可以使用它来加载嵌入式 LDAP 服务器：

dn: ou=groups,dc=tacocloud,dc=com
objectclass: top
objectclass: organizationalUnit
ou: groups
dn: ou=people,dc=tacocloud,dc=com
objectclass: top
objectclass: organizationalUnit
ou: people
dn: uid=buzz,ou=people,dc=tacocloud,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: Buzz Lightyear
sn: Lightyear
uid: buzz
userPassword: password
dn: cn=tacocloud,ou=groups,dc=tacocloud,dc=com
objectclass: top
objectclass: groupOfNames
cn: tacocloud
member: uid=buzz,ou=people,dc=tacocloud,dc=com

　　Spring Security 内置的用户存储非常方便，并且涵盖了最为常用的用户场景。但是，当你的 应用程序需要一些特殊的功能。当开箱即用的用户存储无法满足需求的时候，我们就需要创建和配置自定义的用户详情服务。

　　4.自定义用户认证

　　　　1.新建用户实体类并实现UserDetails接口

@Entity
@Data
@NoArgsConstructor(access=AccessLevel.PRIVATE, force=true)
@RequiredArgsConstructor
public class User implements UserDetails {
    private static final long serialVersionUID = 1L;
    
    @Id
    @GeneratedValue(strategy=GenerationType.AUTO)
    private Long id;
    
    private final String username;
    private final String password;
    private final String fullname;
    private final String street;
    private final String city;
    private final String state;
    private final String zip;
    private final String phoneNumber;
    
    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        return Arrays.asList(new SimpleGrantedAuthority("ROLE_USER"));
    }
    
    @Override
    public boolean isAccountNonExpired() {
        return true;
    }
    
    @Override
    public boolean isAccountNonLocked() {
        return true;
    }
    
    @Override
    public boolean isCredentialsNonExpired() {
        return true;
    }
    
    @Override
    public boolean isEnabled() {
        return true;
    }
}

　　我们的用户实体类实现了Spring Security的UserDetails接口

　　通过实现UserDetails 接口，我们能够提供更多信息给框架，比如用户都被授予了哪些权限以及用户的帐户是否启用。

　　getAuthorities() 方法应该返回用户被授予权限的一个集合。各种 is...Expired() 方法要返回一个boolean值，表明用户的帐户是否可用或过期。

 

　　　　2.定义了 User 实体后，现在可以定义repository接口了

public interface UserRepository extends CrudRepository<User,Long> {
    User findByUsername(String username);
}

　　　　3.创建用户详情接口【需要实现UserDetailsService接口】

@Service
public class UserServiceImpl implements UserDetailsService {

    @Autowired
    private UserRepository userRepository;

    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        User user = userRepository.findByUsername(username);
        if (user != null) {
            return user;
        }
        throw new UsernameNotFoundException("User '" + username + "' not found");
    }
}

　　　　4.将自定义的用户详情服务与Spring Security配置在一起。

    @Qualifier("userServiceImpl")
    @Autowired
    private UserDetailsService userDetailsService;

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.userDetailsService(userDetailsService);
    }

　　在这里， 我们只是简单的调用userDetailsService()方法，并将自动装配到Spring Security Config中的UserDetailsService实例传递了进去即可连接到Spring Security的自定义认证服务。

　　像基于JDBC的认证一样，我们可以（也应该）配置一个密码转码器，这样在数据库中的密码将是转码过的。我们首先需要声明一个PasswordEncoder类型的Bean，然后通过调用passwordEncoder()方法将它注入到用户详情服务中：

    @Qualifier("userServiceImpl")
    @Autowired
    private UserDetailsService userDetailsService;

    @Bean
    public PasswordEncoder encoder(){
        return PasswordEncoderFactories.createDelegatingPasswordEncoder();
    }

    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.userDetailsService(userDetailsService)
                .passwordEncoder(encoder());
    }

⒊保护Web请求

　　当配置完上面的内容后，你会发现你的应用必须获取身份认证才可以正常访问，而我们应用中的一些页面（例如主页、登录页面及注册页面等等）并不需要身份认证便可以访问，为了配置这些安全性规则，需要介绍一下WebSecurityConfigurerAdapter 的另一个 configure() 方法：

@Override
protected void configure(HttpSecurity http) throws Exception {
    ...
}

　　这个 configure() 方法接受一个 HttpSecurity 对象，可以使用该对象来配置如何在 web 级别处理安全性。我们可以使用 HttpSecurity 配置的功能包括：

• 在为某个请求提供服务之前，需要预先满足特定的条件

• 配置自定义登录页面

• 支持用户退出应用

• 配置跨站请求伪造保护

　　配置 HttpSecurity常见的需求就是拦截请求以确保用户具有适当的权限。

　　1. 保护请求

　　我们需要确保只有经过身份认证的用户才能对“/design”和“orders”发起请求，而其他请求则对所有用户均可用。

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
                .antMatchers("/design", "/orders")
                .hasRole("ROLE_USER")
                .antMatchers("/", "/**").permitAll();
    }

　　对 authorizeRequests() 的调用会返回一个对象（ExpressionInterceptUrlRegistry），基于它我们可以指定 URL 路径和这些路径的安全需求。本示例中，我们指定了两条安全规则：

• 具备ROLE_USER 权限的用户才能访问 “/design” 和 “/orders” 

• 其他的请求允许所有用户访问

　　这些规则的顺序是很重要的。声明在前面的安全规则比后面声明的规则有更高的优先级。如果我们交换这两个安全规则的顺序，那么所有的请求都会有permitAll()的规则，对“ /design ”和 “/orders ”声明的规则就不会生效 了。

　　在声明请求路径的安全需求时，hasRole() 和 permitAll() 方法只是众多方法中的两个。下表中列出了所有可用的方法。

方法	能够做什么
access(String)	如果给定的 SpEL 表达式计算结果为 true，就允许访问
anonymous()	允许匿名用户访问
authenticated()	允许认证过的用户访问
denyAll()	无条件拒绝所有访问
fullyAuthenticated()	如果用户是完整认证的（不是通过Remember-me功能认证的）， 则允许访问
hasAnyAuthority(String...)	如果用户具备给定权限中的某一个，则允许访问
hasAnyRole(String...)	如果用户具备给定角色中的某一个，则允许访问
hasAuthority(String)	如果用户具备给定权限，则允许访问
hasIpAddress(String)	如果请求来自给定 IP ，则允许访问
hasRole(String)	如果用户具备给定角色，则允许访问
not()	拒绝任何其他访问方法【对其他访问方法的结果求反】
permitAll()	无条件允许访问
rememberMe()	如果用户是通过Remember-me功能认证的，则允许访问

 

　　上表中的大多数方法为请求处理提供了基本的安全规则，但是它们是自我限制的，也就是只能支持由这些方法所定义的安全规则。除此之外，我们还可以使用 access() 方法，通过为其提供 SpEL 表达式来声明更丰富的安全规则。Spring Security 扩展了 SpEL，包含了多个安全相关的值和函数，如下表所示。

安全表达式	计算结果
authentication	用户的认证对象
denyAll	结果始终为false【通常值为 false】
hasAnyRole(list of roles)	如果用户被授予了列表中任意的指定角色，则为 true
hasRole(role)	如果用户被授予了指定的角色，则为 true
hasIpAddress(IP Address)	如果请求来自指定 IP 地址，则为 true
isAnonymous()	如果当前用户为匿名用户，则为 true
isAuthenticated()	如果当前用户进行了认证，则为 true
isFullyAuthenticated()	如果当前用户进行了完整认证（不是通过Remember-me功能进行 的认证），则为 true
isRememberMe()	如果当前用户是通过Remember-me自动认证的，则为 true
permitAll()	结果始终为true【通常值为 true】
principal	用户的 pricipal 对象

 

 　　我们可以看到，上表中的大多数安全表达式扩展都对应于上上表中的类似方法。实际上，借助 access() 方法和 hasRole() 、 permitAll 表达式，我们可以按如下方式重写 configure()。

 

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
                .antMatchers("/design", "/orders")
                .access("hasRole('ROLE_USER')")
                .antMatchers("/","/**").access("permitAll");
    }

　　看上去，这似乎没什么大不了的。毕竟，这些表达式只是模拟了我们之前通过方法调用已经完成的事情。但是表达式可以更加灵活。例如，假设（基于某种疯狂的原因）我们只允许具有 ROLE_USER 权限的用户在周二创建新的用户；你可以重写表达式如下：

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
                .antMatchers("/design", "/orders")
                .access("hasRole('ROLE_USER') && " +
                        "T(java.util.Calendar).getInstance().get("+
                        "T(java.util.Calendar).DAY_OF_WEEK) == " +
                        "T(java.util.Calendar).TUESDAY")
                .antMatchers("/", "/**").access("permitAll");
    }

　　我们可以使用SpEL实现各种各样的安全性限制。

　　2.创建自定义的登录页

　　为了替换Spring Security内置的登录页面，首先需要告诉 Spring Security 自定义登录页面的路径。这可以通过调用传入到 configure() 的 HttpSecurity 对象的 formLogin() 方法来实现：

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
                .antMatchers("/design", "/orders")
                    .access("hasRole('ROLE_USER')")
                .antMatchers("/", "/**").access("permitAll")

            .and()
                .formLogin()
                .loginPage("/login");
    }

　　请注意，在调用formLogin()之前，我们通过and()方法将这一部分的配置与前面的配置连接在一起。and()方法表示我们已经完成了授权相关的配置，并且要添加一些其他的HTTP配置。在开始新的配置区域时，我们可以多次调用and()。

　　在这个连接之后，我们调用formLogin()开始配置自定义的登录表单。在此之后，对loginPage()的调用声明了我们提供的自定义登录页面的路径。当Spring Security断定用户没有认证并且需要登录的时候，它就会将用户重定向到该路径。

　　默认情况下，Spring Security会在“/login”路径监听登录请求并获取用户名为username和密码为password的请求参数，但这些都是可配置的。举例来说，如下的配置自定义了路径和请求参数的名称：

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
                .antMatchers("/design", "/orders")
                    .access("hasRole('ROLE_USER')")
                .antMatchers("/", "/**").access("permitAll")

            .and()
                .formLogin()
                .loginPage("/login")
                .loginProcessingUrl("/authenticate")
                .usernameParameter("user")
                .passwordParameter("pwd");
    }

　　在这里，我们指定 Spring Security 应该监听对 /authenticate 的请求以处理登录信息的提交。此外，用户名和密码字段已被指定为 user 和 pwd。

　　默认情况下，登录成功之后，用户将会被导航到Spring Security决定让用户登录之前的页面。如果用户直接访问登录页，那么登录成功之后用户将会被导航至根目录（例如，主页）。但是，我们可以通过指定默认的成功页来更改这种行为：

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
                .antMatchers("/design", "/orders")
                    .access("hasRole('ROLE_USER')")
                .antMatchers("/", "/**").access("permitAll")

            .and()
                .formLogin()
                .loginPage("/login")
                .defaultSuccessUrl("/design");
    }

　　按照这个配置，用户直接导航至登录页并且成功登录之后将会被定向到"/design"页面。

　　另外，我们还可以强制用户在登录成功之后统一访问设计页面，即便用户在登陆之前正在访问其他页面，在登录之后也会被定向到设计页面，这可以通过为defaultSuccessUrl方法传递第二个参数true来实现：

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
                .antMatchers("/design", "/orders")
                    .access("hasRole('ROLE_USER')")
                .antMatchers("/", "/**").access("permitAll")

            .and()
                .formLogin()
                .loginPage("/login")
                .defaultSuccessUrl("/design", true);
    }

　　3.退出登录

　　退出和登录是同等重要的，为了启用退出功能，我们只需在HttpSecurity对象上调用logout方法：

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
                .antMatchers("/design", "/orders")
                    .access("hasRole('ROLE_USER')")
                .antMatchers("/", "/**").access("permitAll")

            .and()
                .formLogin()
                .loginPage("/login")
                .defaultSuccessUrl("/design", true)
            .and()
                .logout()
                .logoutSuccessUrl("/");
    }

　　这样会搭建一个安全过滤器，该过滤器会拦截对“/logout”的请求。所以，为了提供退出功能，我们需要为应用的视图添加一个退出表单和按钮。

<form method="POST" th:action="@{/logout}">
    <input type="submit" value="Logout"/>
</form>

　　当用户点击按钮的时候，他们的session将会被清理，这样他们就退出应用了。默认情况下，用户会被重定向到登录页面，这样他们可以重新登录。但是，如果你想要将他们导航到不同的页面，那么可以调用logoutSuccessUrl()指定退出后的不同页面

　　4.防止跨站请求伪造

　　跨站请求伪造（Cross-Site Request Forgery，CSRF）是一种常见的安全攻击。它会让用户在一个恶意设计的 web 页面上填写信息，这个页面会自动（通常是秘密地）将表单以攻击受害者的身份提交到另外一个应用上。例如，用户看到一个来自攻击者的Web站点的表单，这个站点会自动将数据POST到用户银行Web站点的URL上（这个站点可能设计的很糟糕，无法防御这种类型的攻击），实现转账的操作。用户可能根本不知道发生了攻击，直到他们发现账号上的钱已经不翼而飞。

　　为了防止这种类型的攻击，应用可以在展现表单的时候生成一个 CSRF token，并将该 token 放在隐藏域中，然后将其临时存储起来，以便后续在服务器上使用。在提交表单的时候，token 将和表单的其他数据一起发送至服务器。然后服务器拦截请求，并将其与最初生成的 token 进行对比。如果 token 匹配，则允许继续执行请求。否则，表单肯定是由恶意网站渲染的，因为它不知道服务器所生成的token。

　　幸运的是，Spring Security 有内置的 CSRF 保护。更幸运的是，它是默认启用的，不需要显式地配置它。我们唯一需要做的就是确保应用中的每个表单都要有一个名为 _csrf 的字段，该字段包含 CSRF token。

　　Spring Security 甚至进一步简化了将token放到请求的 “_csrf ”属性中这一任务。在 Thymeleaf 模板中，我们可以按照如下的方式在隐藏域中渲染 CSRF token：

<input type="hidden" name="_csrf" th:value="${_csrf.token}"/>

　　如果你使用 Spring MVC 的 JSP 标签库或者Spring Security的 Thymeleaf 方言，那么甚至都不用明确包含这个隐藏域（这个隐藏域会自动生成）

　　在 Thymeleaf 中，只需确保 <form> 的某个属性带有 Thymeleaf 属性前缀即可。通常这并不是什么问题，因为我们一般会使用 Thymeleaf 渲染相对于上下文的路径。例如，为了让Thymeleaf 渲染隐藏域，我们只需要使用 th:action 属性就可以了：

<form method="POST" th:action="@{/login}" id="loginForm">

　　我们也可以禁用 CSRF 支持，CSRF 防护很重要，而且在表单中很容易实现，所以没有理由禁用它，但如果你坚持禁用它，那么可以通过调用 disable()来实现：

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
                .antMatchers("/design", "/orders")
                    .access("hasRole('ROLE_USER')")
                .antMatchers("/", "/**").access("permitAll")

            .and()
                .formLogin()
                .loginPage("/login")
                .defaultSuccessUrl("/design", true)
            .and()
                .logout()
                .logoutSuccessUrl("/")
            .and()
                .csrf()
                .disable();
    }

　　再次强调，不要禁用 CSRF 保护，特别是对于生产环境中的应用程序。

⒋获取系统中已登录的用户信息

　　通常，仅仅知道用户已登录是不够的，我们一般还需要知道他们是谁，这样才能优化体验。

　　我们有多种方式确定用户是谁，常用的方式如下：

• 注入Principal对象到控制器方法中
• 注入Authentication对象到控制器方法中
• 使用@AuthenticationPrincipal注解来标注方法
• 使用SecurityContextHolder来获取安全上下文

　　1.注入Principal对象到控制器方法中

    @PostMapping
    public User getLoginUser(Principal principal){
        User user = userRepository.findByUsername(principal.getName());
        return user;
    }

　　这种方式能够正常运行，但是它会在与安全无关的功能中掺杂安全性的代码，我们可以修改这个方法，让它不再接受Principal参数，而是接受Authentication对象作为参数：

　　2.注入Authentication对象到控制器方法中

    @PostMapping
    public User getLoginUser(Authentication authentication){
        User user = null;
        if(authentication.getPrincipal() instanceof  User){
            user = (User) authentication.getPrincipal();
        }
        return user;
    }

　　有了Authentication对象之后，我们就可以调用getPrincipal()来获取principal对象，在本例中，也就是一个User对象。需要注意，getPrincipal()返回的是java.util.Object，所以我们需要将其转换成User。

　　3.使用@AuthenticationPrincipal注解来标注方法

　　最整洁的方案可能是在该方法中直接接受一个User对象，不过我们需要为其添加@AuthenticationPrincipal注解，这样它才会变成认证的principal。

    @PostMapping
    public User getLoginUser(@AuthenticationPrincipal User user){
        return user;
    }

　　@AuthenticationPrincipal非常好的一点在于它不需要类型转换（上面的Authentication则需要进行类型转换），同时能够将安全相关的代码仅仅局限于注解本身。

　　

　　4.使用SecurityContextHolder来获取安全上下文

　　还有另外一种方式能够识别当前认证用户是谁，但是这种方式有点麻烦，它会包含大量安全性相关的代码。我们可以从安全上下文中获取一个Authentication对象，然后像下面这样获取它的principal：

    @PostMapping
    public User getLoginUser(){
        Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
        User user = (User)authentication.getPrincipal();
        return user;
    }

　　尽管这个代码片段充满了安全性相关的代码，但是它与前面的其他方法相比有一个优势：它可以在应用的任何地方使用，而不仅仅是在控制器的处理器方法中，这使得它非常适合在较低级别的代码中使用。