강의에서 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 에 저장하고 꺼낼 수 있다고 이해했는데 맞을까요?
- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 우선 강의 정말 유익하게 잘 보고 있습니다 감사합니다 ! 9분대에 질문이 있습니다. 어떻게 A의 개인 키로 잠겨 있는 것을 A의 공개 키로 오픈 할 수 있나요? -> 공개 키로 잠궈놨다면 해커가 열 수 있다고 생각 하는데, 개인키로 잠군 것을 B나 해커가 어떻게 공개 키로 열람할 수 있는 것인가요 ? A -> B 로 "A:C:1억을 송금했다" 라는 메시지를 A의 개인키로 보낼때 해커가 가로채서 A의 공개키를 사용해 데이터를 열어볼 수 있다고 하셨는데, 그럼 해커가 저 데이터를 다시 변경하여 B로 이상한 메시지를 보낼 수 있나요? 2-1. 보낼 수 있게 된다면 해커가 다시 A의 개인 키로 데이터를 보내나요? 2-2. 그렇게 된다면 B는 해커한테 탈취를 당했었는지 어떻게 식별 하나요? 해커가 다시 A의 개인 키를 사용할 수 있나요 ? 질문이 좀 많아서 죄송합니다 ㅎㅎ ..
안녕하세요. 호돌맨님 인강 들으면서 어찌저찌 취업하게 된 신입 개발자입니다. 현재 postDelete 로 단일 데이터를 검증 후 삭제하고있는데, 만약 List로 된 다중 PK 를 검증하고 삭제할 때는 어느 방법이 좋은건지 잘 모르겠습니다. public void postAllDelete(List<Long> postIds) { //1번 List<Post> posts = postRepository.findAllById(postIds); if(posts.isEmpty()) throw new IllegalArgumentException("삭제할 게시글이 존재하지 않습니다."); postRepository.deleteAll(posts); //2번 postIds.forEach(e-> { Post post = postRepository.findById(e) .orElseThrow(PostNotFound::new); postRepository.delete(post); }); } 1번 같은 경우는 조회 및 삭제 각 한번씩 DB 를 호출해서 성능적으로 좋다고 생각하는데, 리스트에 담겨져있는 PK 가 유효한지 검증하려면 stream API 를 사용하여 map 으로 PK 추출 후 filter 로 검증을 하는게 좋은건지, 혹은 다른 방법이 있는지 궁금합니다 물론 현재는 데이터가 많이 없으니 어느 방법을 채택해도 상관없지만 추후에 대량의 데이터를 접하게될 때를 생각하다보니,, 어떻게 보면 인강과 관련없는 질문이긴한데,, 염치 불구하고 도움 주시면 감사하겠습니다.
안녕하세요. 좋은 강의 올려주셔서 감사하게 잘 듣고 있습니다. Authencation 클래스에 대해서 배우면서 궁금한 점이 생겼습니다. Authentication 클래시는 인증을 할 때, 그리고 인증 후에 인증에 대한 정보로서 두 상황에서 쓰이는 거 같습니다. 그런데 사실 이 두 상황은 상당히 다른 것 같고, 그다지 동일한 값을 쓰지도 않는 것 같습니다. 예를 들어, getCredentials는 인증 할 때만 쓰이고, isAuthenticated같은 경우는 인증 후에만 쓰일 것 같습니다. 이렇게 다른 상황에 쓰이는데도 Authentication 클래스 하나로 합쳐서 쓰는 이유가 있나요? 둘을 구분해 각각의 클래스로 제공하면 더 깔끔할거 같다는 생각이 들어 질문드려봅니다.
요청 기반 권한 부여 - 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(); } 이상으로 내용 공유를 마칩니다.
안녕하세요 선생님, 현재 프로젝트에서 프로덕션에서 사용하는 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를 넣는 방식을 사용했습니다
해당 필터는 단순히 Supplier로 감싸진 CsrfToken 을 getToken ()을 통해서 초기화를 진행하고 있습니다 GET 방식이면 어차피 CsrfFilte r에서 바로 다음 필터로 넘어가고 POST면 CsrfFilter 에서 토큰 비교를 하기 위해서 초기화를 CsrfFilter 에서 하는데 CsrfCookieFilter 는 왜 필요할까요? 여러 가지 케이스로 디버깅하면서 좀 더 살펴봤는데 특정 페이지에서 POST 요청을 하는 버튼이 있으면 먼저 CSRF 토큰을 발급해서 클라이언트에 저장이 되어있어야 POST 요청에서 토큰을 쿠키에 꺼내어 검증할 수 있기 때문에 GET 요청에도 getToken()을 통해서 초기화가 진행되고 해당 초기화 과정에 saveCookie 로직이 있기 때문에 클라이언트 쿠키에 토큰이 저장되는 걸로 추측했습니다
CSRF 통합 강의에서 17분쯤에 user 1111 계정이 아니라 ddd로 입력을 하시는데 UserDetails로 설정 하지 않으신 것 같은데 어떻게 로그인이 되는 건지 궁금합니다. 로그인 후 Whitelabel Error가 뜨는 경우는 어떤 부분을 수정하면 될까요? 이 강의를 수강하면서 해당 오류가 많았습니다. 로그인이 된 경우도 있고 안 된 경우도 있었습니다.
현재 지금 프론트와 백엔드로 나누어져 웹 개발을 하고 있습니다 여기서 궁금한점은 선생님 코드를 다 따라 적었는데 프론트에서 로그인 요청을 해서 로그인한 이후 프론트에서 메인 페이지로 보내는데 거기서 다음 기능을 쓰려고 하면 서버 500에러가 뜨고 어나니머스필터가 요청을 받는거 같습니다 저도 정확하게 알 수 없어서 그런데 혹시 CSRF기능을 안써서 어나니머스필터로 가는 것인지 아니면 뭐가 잘못 된건지 알 수 없습니다 좀 알려주시면 감사하겠습니다
