• 카테고리

    질문 & 답변
  • 세부 분야

    백엔드

  • 해결 여부

    해결됨

변경된 시큐리티의 filterChain에서 and() 메서드 사용은 권장하지 않나요?

23.03.30 11:50 작성 23.03.30 11:51 수정 조회수 458

0

기존 상속 받아서 사용하던 것 처럼 변경된 filterChain에서도 and() 메서드를 사용해서 옵션들을 빌더 연결 패턴 처럼 사용할 수 있던데 변경된 시큐리티에선 권장하지 않는 방법인지, 아니면 가독성 때문인지 궁금합니다!

 

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    log.debug("디버그: filterChain 빈 등록됨");
    http.headers().frameOptions().disable()
            .and()
            .csrf().disable()
            .cors().configurationSource(configurationSource())
            .and()
            .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
            .and()
            .formLogin().disable()
            .httpBasic().disable()
            .apply(new CustomSecurityFilterManager())
            .and()
            .exceptionHandling().authenticationEntryPoint((request, response, authException) -> {
                CustomResponseUtil.fail(response, "로그인을 진행해 주세요", HttpStatus.UNAUTHORIZED);
            })
            .and()
            .exceptionHandling().accessDeniedHandler((request, response, e) -> {
                CustomResponseUtil.fail(response, "권한이 없습니다", HttpStatus.FORBIDDEN);
            })
            .and()
            .authorizeRequests()
            .antMatchers("/api/s/**").authenticated()
            .antMatchers("/api/admin/**").hasRole("" + UserEnum.ADMIN)
            .anyRequest().permitAll();
    return http.build();
}

 

답변 1

답변을 작성해보세요.

1

권장 사항이라기 보다는 공식문서에 아래와 같이 람다로 작성되어 있습니다.

image

기존 코드에서 사용할 수 있는 것은 그대로 유지하고, 변경된 부분인 hasRole("_ROLE_ADMIN") 이런 부분들만 부분적으로 수정하여 코드를 작성하였습니다.

여러 승인 규칙이 지정되었습니다. 각 규칙은 선언된 순서대로 고려됩니다.
모든 사용자가 액세스할 수 있는 여러 URL 패턴을 지정했습니다. 특히 URL이 "/resources/"로 시작하거나 "/signup"과 같거나 "/about"과 같으면 모든 사용자가 요청에 액세스할 수 있습니다.
"/admin/"으로 시작하는 모든 URL은 "ROLE_ADMIN" 역할을 가진 사용자로 제한됩니다. 메서드를 호출하기 때문에 hasRole"ROLE_" 접두사를 지정할 필요가 없습니다.
"/db/"로 시작하는 모든 URL은 사용자에게 "ROLE_ADMIN"과 "ROLE_DBA"가 모두 있어야 합니다. hasRole"ROLE_" 접두사를 지정할 필요가 없는 표현식을 사용하고 있음을 알 수 있습니다 .
4의 동일한 규칙은 여러 개를 결합하여 작성할 수 있습니다 AuthorizationManager.
아직 일치하지 않은 URL은 액세스가 거부됩니다. 권한 부여 규칙 업데이트를 실수로 잊고 싶지 않은 경우에 좋은 전략입니다.

무엇이 좋다, 안좋다 그런 부분은 저도 잘모르겠습니다. 권장사항이라기 보다는 공식문서에 나와있으니 따라해서 작성하셔도 됩니다. 저는 이런 부분을 크게 신경쓰지 않습니다. 결국 코드이기 때문에!!

코드 최신화를 원한다면 아래 문서 참고하시면서 개발하시면 도움 되실 것 같습니다.
https://docs.spring.io/spring-security/reference/servlet/authorization/index.html

 

답변이 크게 도움이 되지 못한것 같습니다!!