WebUtil이 지원하지 않는거 같은데 맞을까요?(WebUtils만 보이네요)

실제로 UserDetails를 구현하고 있는 건 "AccountContext" 이지 "AccountDTO"가 아니기 때문에, @AuthenticationPrincipal AccountDto accountDto를 하면 null이 반환될 수 있지 않나요?그래서 차라리 @AuthenticationPrincipal AccountContext accountContext를 해서 if (accountContext != null) { model.addAttribute("username", accountContext.getUsername()); } else { model.addAttribute("username", "비회원");}이렇게 하는게 더욱 올바른 방법이 아닌가요?

강의를 다시 복습하니, SecurityContextHolder 가 지연로딩을 해 주는 역할도 하지만 다른 필터에 SecurityContext를 전달하는 DTO 같은 역할을 하는 것 같다고 느꼈는데 선생님 생각은 어떠신가요?

선생님 , 안녕하세요. 강의 잘듣고 있습니다!질문이 있어서 글남기게 됩니다! 이번 강의 9분 50초 정도에 AuthoriationManger 인터페이스는 접근제어자가 public으로 되어있는데, 하위 메서드인 verify는 접근제어자가 default로 되어있습니다! 위의 이유가 궁금합니다. AuthrozationManager 와 같은 패키지내의 클래스에서만 verify 메서드에 접근 가능하도록 제한을 두기 위한 것인지 아니면 다른 이유가 있는지 궁금합니다.답변 부탁드리겠습니다! 항상 좋은 강의 감사드립니다.

강의 중간 (18: 15)에 커스텀 ExpressionHandler를 만들기 위해 setApplicationContext() 로 스프링 컨테이너를 필드값으로 set 했는데 스프링 컨테이너가 필요한 이유가 무엇인지 궁금합니다.

SecurityFilterChain 의 순서를 보면 AnonymousAuthenticationFilter 가 먼저이고 AuthorizationFilter 가 맨 마지막에 실행되는 것을 확인했습니다. Anonymous 강의에서 AnonymousAuthenticaionFilter는 authentication이 null 인 경우 AnonymousAuthenticaionToken을 생성하여 익명 사용자로 처리한고 Authentication이 null이 아닌 경우 doFilter()로 다음필터로 넘어간다고 하셨는데.오늘 강의를 보니 anonymousAuthenticationFilter 에는 authenticaion 이 있는지 확인을 하지 않고 authorizationFilter 에서 getContext().getAuthentication() 을 통해 유무를 확인후 없다면 다시 AnonymousAuthenticationFilter 를 통해 AnonymousAuthenticationToken을 생성시켜 할당하는 것 처럼 보이는데 맞을까요?즉 anonymousAuthenticationFilter doFilter() --> AuthorizationFilter getAuthentication() --> anonymousAuthenticationFilter에서 생성

강의를 듣다가 궁금해서 좀 찾아봤습니다(Perplxtiy에게 물어본거라 신뢰도가 100%는 아닙니다) 만료된 세션을 처리하려면 expiredUrl 설정이 필수여서 invalidUrl 설정 단독으로는 처리를 못한다고 합니다 그럼 2개가 다 설정되도 expiredUrl을 타는게 맞는것 같지만 Filter chain의 우선순위때문에 expiredUrl을 즉 만료된 세션을 invalidUrl로 간주하고 invalidUrl이 실행되는 것 같습니다

해당 강의를 학습하던 도중 indexController 의 다음 메서드가 어떻게 익명사용자인것을 알아채고 해당 토큰을 남기는 걸까 의문점이 생겨 질문을 남깁니다. @GetMapping("/anonymousContext") public String anonymousContext(@CurrentSecurityContext SecurityContext context) { return context.getAuthentication().getName(); } 해당의문을 해결하기 위해 localhost:8080/anonymousContext 가 호출될 때 서버는 어떤 과정을 거칠까 생각해보고 다음과 같은 결론을 냈습니다. 1. localhost:8080/anonymousContext 가 호출될 때, Authentication 이 null 값인 것을 확인한다2. AnonymousAuthenticationToken을 생성하여 SecurityContextHolder에 저장한다.3. Jsession이 없는 것을 확인하고 AnonymousAuthenticationToken이 저장된 SecurityContext를 파라미터로 넘긴다.4. 해당 포큰이 getName() 값이 출력된다.이러한 과정을 거칠거라 생각한 이유는 로그인 상태에서 localhost:8080/anonymousContext 를 호출하게 될 때, "user"라는 값이 출력되는 것을 확인했고 두 같은 요청값에 유일한 차이는 쿠키에 Jsession의 유무였기 때문입니다. SecurityContext가 anonymous 를 판단하는 기준이 제가 생각한 것과 같을까요?

강의에서 SecurityBuilder를 통해 생성된 SecurityFilterChain 을 저장한다는 설명과 관련해서 어떤 코드가 실행하는지 분석을 나름 해보았는데요, 맞는지 확인받고 싶습니다. WebSecurityConfiguration 클래스에 springSecurityFilterChain() 메서드에 다음과 같은 코드가 있습니다.for(SecurityFilterChain securityFilterChain : this.securityFilterChains) { this.webSecurity.addSecurityFilterChainBuilder(() -> securityFilterChain); }해당 코드에서 addSecurityFilterChainBuilder() 메서드는 SecurityBuilder<O extends SecurityFilterChain> securityFilterChainBuilder 를 파라미터로 받고 있는데,해당 파라미터로 람다식을 이용해서 HttpSecurity에서 생성한 객체를 SecurityBuilder의 build() 메서드를 호출시 리턴할 수 있게 () -> securityFilterChain 했고 해당 람다식이 addSecurityFilterChainBuilder() 메서드로 인해 WebSecurity 필드인 securityFilterChainBuilders 에 저장이 되었습니다.저장된 람다식은 WebSecurity 에 performBuild() 메서드에 구현되어 있는 for(SecurityBuilder<? extends SecurityFilterChain> securityFilterChainBuilder : this.securityFilterChainBuilders) { SecurityFilterChain securityFilterChain = (SecurityFilterChain)securityFilterChainBuilder.build();다음과 같은 for 문에서 build() 메서드를 호출하면서 SecurityFilterChain 객체를 불러오게 됩니다. 다음과 같은 과정으로 SecurityBuilder 에 저장하고 꺼낼 수 있다고 이해했는데 맞을까요?

안녕하세요. 좋은 강의 올려주셔서 감사하게 잘 듣고 있습니다. Authencation 클래스에 대해서 배우면서 궁금한 점이 생겼습니다. Authentication 클래시는 인증을 할 때, 그리고 인증 후에 인증에 대한 정보로서 두 상황에서 쓰이는 거 같습니다. 그런데 사실 이 두 상황은 상당히 다른 것 같고, 그다지 동일한 값을 쓰지도 않는 것 같습니다. 예를 들어, getCredentials는 인증 할 때만 쓰이고, isAuthenticated같은 경우는 인증 후에만 쓰일 것 같습니다.  이렇게 다른 상황에 쓰이는데도 Authentication 클래스 하나로 합쳐서 쓰는 이유가 있나요? 둘을 구분해 각각의 클래스로 제공하면 더 깔끔할거 같다는 생각이 들어 질문드려봅니다.

안녕하세요 선생님, [커스텀 인증실패 핸들러 - AuthenticationFailureHandler (08:11) ] 강의를 듣다가 의문점이 생겨서 문의드립니다. 현재 AuthenticationFailureHandler 를 extend 해서 사용 중인데 FormAuthenticationFailureHandler.onAuthenticationFailure 메소드에서 아래처럼 defaultFailureUrl 을 변경하는 부분이 있습니다.@Component public class FormAuthenticationFailureHandler extends SimpleUrlAuthenticationFailureHandler { @Override public void onAuthenticationFailure(HttpServletRequest request, HttpServletResponse response, AuthenticationException exception) throws IOException, ServletException { String errorMessage = "Invalid Username or Password"; if (exception instanceof BadCredentialsException) { errorMessage = "Invalid Username or Password"; } else if (exception instanceof UsernameNotFoundException) { errorMessage = "User not exists"; } else if (exception instanceof CredentialsExpiredException) { errorMessage = "Expired password"; } else if (exception instanceof SecretException) { errorMessage = "Invalid Secret Key"; } // Thread Safe...? setDefaultFailureUrl("/login?error=true&exception=" + errorMessage); super.onAuthenticationFailure(request, response, exception); } }이 setDefaultFailureUrl 메소드를 호출해서 모든 쓰레드가 접근할 수 있는 defaultFailureUrl 필드를 변경하는 건 Thread Safe 하지 않지 않나요??  

요청 기반 권한 부여 - HttpSecurity.securityMatch 강의 (14분 25초) 를 듣고 코드를 똑같이 따라 치고 실행해보니 에러가 뜨면서 동작을 안 하더군요. spring boot 버전은 3.4.1 + spring security 6.4.2 로 테스트를 해봤습니다. 조사를 해보니 에러를 뱉는 건 스프링 시큐리티의 WebSecurity 클래스였고, 아래 빨간 박스 친 부분에서 에러를 뱉습니다.  이 코드는 securityMatcher 를 설정 안 한 SecurityFilterChain, 즉 anyRequestFilterChain 이 모든 FilterChain 들 보다 항상 뒤편에 있어야 되는 것을 보장하기 위한 유효성 검사를 위한 것입니다. 선생님이 강의를 찍던 당시와 달라진 내용이 아닐까 싶습니다. 아무튼 이를 우회해서 테스트를 할 수 있는데, 선생님이 작성하신 코드에서 딱 한줄만 추가해주면 됩니다. @Bean @Order(1) public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { // !!!!!!!!!!!!!!! 아래 한 줄 추가 !!!!!!!!!!!!!!! http.securityMatchers(matcher -> matcher.requestMatchers("/**")); http.authorizeHttpRequests(auth -> { auth.anyRequest().authenticated(); }) .formLogin(Customizer.withDefaults()); return http.build(); } @Bean public SecurityFilterChain securityFilterChain2(HttpSecurity http) throws Exception { http.securityMatchers(matchers -> matchers.requestMatchers("/api/**", "/oauth/**")); http.authorizeHttpRequests(auth -> { auth.anyRequest().permitAll(); }); return http.build(); } 이상으로 내용 공유를 마칩니다. 

5강에서 11개의 configurer가 생성된다고 하셨는데제꺼에서는 CorsConfigurer를 제외한 10개만 생성이 됩니다.왜 이런지 알 수 있을까요?

이렇게 안뜨고이렇게 떠 있는데 어떻게 프로젝트를 생성해야하는지 모르겠습니다 ㅠㅠ

안녕하세요 선생님,현재 프로젝트에서 프로덕션에서 사용하는 SecurityConfig클래스와 테스트에서 사용하는 SecurityConfig를 다르게 가져가려 합니다. 이유는 프로덕션 환경에서는 jwt필터 같이 커스텀 필터들을 적용해야하고, 테스트 환경에서는 해당 필터들을 거치지 않도록 해서 테스트를 더 편하게 하기 위함입니다.@Configuration @EnableWebSecurity public class SecurityConfig { @Bean("prodSecurityFilterChain") public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {...} ... http.addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class); ... }@TestConfiguration @EnableWebSecurity public class TestSecurityConfig { @Bean("testSecurityFilterChain") public SecurityFilterChain testSecurityFilterChain(HttpSecurity http) throws Exception {...} //필터 없음 }위 처럼 작성하였습니다.컨트롤러 테스트 시@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) @ActiveProfiles("test") public class InterfaceTest { @LocalServerPort private int port; @BeforeEach void setUp() { RestAssured.port = port; } }위의 클래스를 상속받아서 테스트를 구현합니다. 제 의도는 테스트 시에는 @TestConfiguration이 주어진 SecurityConfig를 기반으로 설정이 될거고TestSecurityConfig에는 jwt필터가 없으니, 테스트 코드에서는 필터를 거치지 않고 잘 수행이 될거다 였으나, 실제 Security 디버그를 보면 2024-12-11 10:17:32 [Test worker] DEBUG org.springframework.security.web.DefaultSecurityFilterChain - Will secure any request with filters: DisableEncodeUrlFilter, WebAsyncManagerIntegrationFilter, SecurityContextHolderFilter, HeaderWriterFilter, CorsFilter, LogoutFilter, BlackListCheckFilter, JwtAuthenticationFilter, RequestCacheAwareFilter, SecurityContextHolderAwareRequestFilter, AnonymousAuthenticationFilter, SessionManagementFilter, ExceptionTranslationFilter, AuthorizationFilter로 JwtAuthenticationFilter가 있으며, 인증처리가 안되었다는 401에러를 뱉고있습니다.질문 드립니다.1. 프로덕션 환경과 테스트 환경 Config구분시 별도의 설정이 더 필요할까요? 자료들을 더 찾아보아도 다른 방법이 없어서 질문드립니다.2. 혹시 Config를 구분하는것이 아예 불가능한것일까요??아니라면, 실무에서도 위와 같은 구조가 자주 사용되는지 등 궁금합니다.

@EnableWebSecurity @Configuration public class SecurityConfig { @Bean public SecurityFilterChain securityFilterChain(HttpSecurity http, HandlerMappingIntrospector introspector) throws Exception{ http .addFilterAt(authorizationFilter(introspector), AuthorizationFilter.class) .formLogin(Customizer.withDefaults()) .csrf(AbstractHttpConfigurer::disable); return http.build(); } @Bean public AuthorizationFilter authorizationFilter(HandlerMappingIntrospector introspector){ List<RequestMatcherEntry<AuthorizationManager<RequestAuthorizationContext>>> mappings = new ArrayList<>(); RequestMatcherEntry<AuthorizationManager<RequestAuthorizationContext>> requestMatcherEntry1 = new RequestMatcherEntry<>( new MvcRequestMatcher(introspector, "/user"), AuthorityAuthorizationManager.hasAuthority("ROLE_USER")); RequestMatcherEntry<AuthorizationManager<RequestAuthorizationContext>> requestMatcherEntry2 = new RequestMatcherEntry<>( new MvcRequestMatcher(introspector, "/db"), AuthorityAuthorizationManager.hasAuthority("ROLE_DB")); RequestMatcherEntry<AuthorizationManager<RequestAuthorizationContext>> requestMatcherEntry3 = new RequestMatcherEntry<>( new MvcRequestMatcher(introspector, "/admin"), AuthorityAuthorizationManager.hasAuthority("ROLE_ADMIN")); RequestMatcherEntry<AuthorizationManager<RequestAuthorizationContext>> requestMatcherEntry4 = new RequestMatcherEntry<>( AnyRequestMatcher.INSTANCE, // default strategy = AuthenticatedAuthorizationStrategy new AuthenticatedAuthorizationManager<>()); mappings.add(requestMatcherEntry1); mappings.add(requestMatcherEntry2); mappings.add(requestMatcherEntry3); mappings.add(requestMatcherEntry4); RequestMatcherDelegatingAuthorizationManager manager = RequestMatcherDelegatingAuthorizationManager.builder() .mappings(maps -> maps.addAll(mappings)).build(); return new AuthorizationFilter(manager); } @Bean public UserDetailsService userDetailsService(){ UserDetails user = User.withUsername("user").password("{noop}1111").roles("USER").build(); UserDetails db = User.withUsername("db").password("{noop}1111").authorities("ROLE_DB").build(); UserDetails admin = User.withUsername("admin").password("{noop}1111").roles("ADMIN","SECURE").build(); return new InMemoryUserDetailsManager(user, db, admin); } }필터에 직접 RequestMatcherDelegatingAuthorizationManager를 넣는 방식으로 개선해 봤습니다 처음에는 RequestMatcherDelegatingAuthorizationManager -> RequestMatcherDelegatingAuthorizationManager 구조로 바꾸려고 했는데 access()에는 AuthorizationManager<RequestAuthorizationContext>만 가능해서 AuthorizationManager<HttpServletRequest>인 RequestMatcherDelegatingAuthorizationManager를 바로 못 넣더라구요 그래서 필터를 생성하고 필터 생성자로 RequestMatcherDelegatingAuthorizationManager를 넣는 방식을 사용했습니다

테스트 중 사용된 메소드가 곧 Deprecated 된다고 나오는데 혹시 다른 메소드 설정 방법 알려주실 수 있을까요?

해당 필터는 단순히 Supplier로 감싸진 CsrfToken을 getToken()을 통해서 초기화를 진행하고 있습니다 GET 방식이면 어차피 CsrfFilter에서 바로 다음 필터로 넘어가고 POST면 CsrfFilter에서 토큰 비교를 하기 위해서 초기화를 CsrfFilter에서 하는데 CsrfCookieFilter는 왜 필요할까요? 여러 가지 케이스로 디버깅하면서 좀 더 살펴봤는데특정 페이지에서 POST 요청을 하는 버튼이 있으면 먼저 CSRF 토큰을 발급해서 클라이언트에 저장이 되어있어야 POST 요청에서 토큰을 쿠키에 꺼내어 검증할 수 있기 때문에GET 요청에도 getToken()을 통해서 초기화가 진행되고 해당 초기화 과정에 saveCookie 로직이 있기 때문에클라이언트 쿠키에 토큰이 저장되는 걸로 추측했습니다

로그인한 사용자가 저의 localhost8080서버가 다시 재작동해도 로그인이 유지되게하는 강의 내용도있을가요?

CSRF 통합 강의에서 17분쯤에 user 1111 계정이 아니라 ddd로 입력을 하시는데 UserDetails로 설정 하지 않으신 것 같은데 어떻게 로그인이 되는 건지 궁금합니다.로그인 후 Whitelabel Error가 뜨는 경우는 어떤 부분을 수정하면 될까요? 이 강의를 수강하면서 해당 오류가 많았습니다. 로그인이 된 경우도 있고 안 된 경우도 있었습니다.