websecurityconfigureradapter가 deprecated되었다

충격적인 소식 websecurityconfigureradapter deprecated...

 

그저 강의를 따라가는 나한텐 아주 큰 충격이 아닐 수 없었다.

맨날 한 걸음마다 삐걱대는게 마음에 안 들었는데 이번에 아주 그냥 넘어져버렸다

하지만 이를 포스팅 안할순 없지

 

 

이유부터 알아보자

websecurityconfigureradapter가 deprecated 된 이유

지금까지.. 아니지 멀지 않은 과거엔 websecurityconfigureradapter를 사용해 spring Security관련 설정을 했다

@Configuration
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
	...
}

이런 식으로 상속을 받아서 메소드를 오버라이드하여 아주 맛깔나게 써왔다.

하지만 Spring은 과감히 없애버리고 만다.  component-based security configuration의 사용자들의 전환을 격려하기 위함...이라고 한다 뭔지 잘 모르겠다..

어쨋든! 우리는 그것이 중요한 것이 아니라 이제 이것을 어떻게 사용할 것 인가에 더욱더 초점을 둬야 한다

 

기존에 사용하는 HttpSecurity방식을 먼저 보자

@Configuration
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests((authz) -> authz
            .anyMatchers().authenticated())
            .httpBasic(withDefaults());
    }
}

늘 보던 방식이다. 필자는 늘 보진 않고 이번에 security 공부하면서 처음 본다...

자 그럼 바꾸려면 어떻게 적어야 할까?

@Configuration
public class SecurityConfiguration {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.authorizeHttpRequests((authz) -> authz
            .requestMatchers().authenticated())
            .httpBasic(withDefaults());
        return http.build();
    }
}

이런 식으로 바뀌었다 차이가 뭘까?

아주 큰 차이는 역시 상속받는 websecurityconfigureradapter가 없어진 것이다.

그리고 또 하나 authorizeHttpRequests의 차이이다.

authorizeRequests 또한 아쉽게도 deprecated가 되었다고 한다. 그렇게 바뀌게 되면서 또다른 메서드도 같이 아주 조금씩 바뀌었다 신경써서 사용해야겠다

뭐 큰 맥락이 사라지면 밑에 있는 아이도 자연스레 바뀌는 건 인정할 수밖에 없는 일이다. 

 

정리를 한번 해보자면

기존의 WebSecurityConfigurerAdapter를 상속받고 configure 메서드를 오버라이딩하여 설정들을 정의했다면
바뀐 방식은 configure 메서드를 오버라이딩하는 방식이 아닌 설정들을 하나의 Bean으로 등록하고 SecurityFilterChain으로 return 한다