FileCodeBox

12.5.1 Cấu hình bảo mật web phản ứng

Như đã nhắc lại, việc cấu hình Spring Security để bảo vệ một ứng dụng web Spring MVC thường liên quan đến việc tạo một lớp cấu hình mới mở rộng WebSecurityConfigurerAdapter và được chú thích với @EnableWebSecurity. Lớp cấu hình như vậy sẽ ghi đè phương thức configure() để chỉ định các chi tiết bảo mật web như các quyền truy cập cần thiết cho các đường dẫn yêu cầu nhất định. Lớp cấu hình bảo mật Spring Security đơn giản sau đây là một lời nhắc về cách cấu hình bảo mật cho một ứng dụng Spring MVC không phản ứng:

java

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

  @Override
  protected void configure(HttpSecurity http) throws Exception {
    http
      .authorizeRequests()
        .antMatchers("/api/tacos", "/orders").hasAuthority("USER")
        .antMatchers("/**").permitAll();
  }

}

Giờ hãy xem cấu hình này sẽ trông như thế nào đối với một ứng dụng Spring WebFlux phản ứng. Danh sách sau hiển thị một lớp cấu hình bảo mật phản ứng có chức năng tương đương với cấu hình bảo mật đơn giản trước đó.

Danh sách 12.12 Cấu hình Spring Security cho một ứng dụng Spring WebFlux

java

@Configuration
@EnableWebFluxSecurity
public class SecurityConfig {

@Bean
public SecurityWebFilterChain securityWebFilterChain(
                        ServerHttpSecurity http) {
  return http
    .authorizeExchange()
      .pathMatchers("/api/tacos", "/orders").hasAuthority("USER")
      .anyExchange().permitAll()
    .and()
      .build();
  }

}

Như bạn thấy, có nhiều điểm quen thuộc, mặc dù đồng thời cũng có nhiều điểm khác biệt. Thay vì @EnableWebSecurity, lớp cấu hình mới này được chú thích bằng @EnableWebFluxSecurity. Hơn nữa, lớp cấu hình không mở rộng WebSecurityConfigurerAdapter hay bất kỳ lớp cơ sở nào khác. Do đó, nó cũng không ghi đè bất kỳ phương thức configure() nào.

Thay vì một phương thức configure(), bạn khai báo một bean có kiểu SecurityWebFilterChain với phương thức securityWebFilterChain(). Phần thân của securityWebFilterChain() không khác nhiều so với phương thức configure() trước đó, nhưng có một số thay đổi tinh tế.

Chủ yếu, cấu hình được khai báo bằng cách sử dụng một đối tượng ServerHttpSecurity thay vì một đối tượng HttpSecurity. Sử dụng ServerHttpSecurity được cung cấp, bạn có thể gọi authorizeExchange(), tương đương với authorizeRequests(), để khai báo các quy tắc bảo mật ở cấp độ yêu cầu.

LƯU Ý: ServerHttpSecurity là mới trong Spring Security 5 và là đối tượng tương đương phản ứng với HttpSecurity.

Khi so khớp đường dẫn, bạn vẫn có thể sử dụng các đường dẫn ký tự đại diện kiểu Ant, nhưng sử dụng phương thức pathMatchers() thay vì antMatchers(). Và như một tiện ích, bạn không còn cần chỉ định một đường dẫn kiểu Ant bao quát như /** vì anyExchange() đã trả về phần bao quát cần thiết.

Cuối cùng, vì bạn đang khai báo SecurityWebFilterChain như một bean thay vì ghi đè một phương thức của framework, bạn phải gọi phương thức build() để tập hợp tất cả các quy tắc bảo mật vào SecurityWebFilterChain sẽ được trả về.

Ngoài những khác biệt nhỏ đó, việc cấu hình bảo mật web không khác nhiều giữa Spring WebFlux và Spring MVC. Nhưng còn chi tiết người dùng thì sao?

12.5.1 Cấu hình bảo mật web phản ứng ​

12.5.1 Cấu hình bảo mật web phản ứng