RequestMatcherDelegatingAuthorizationManager 로 인가 설정 응용하기에서 질문이 있습니

Spring은 @Bean 메서드에서 파라미터가 있는 경우, 해당 파라미터의 타입에 맞는 빈을 애플리케이션 컨텍스트에서 찾아 자동으로 주입한다

섹션 9 계층적 권한 메소드 Deprecated

@Bean public RoleHierarchy roleHierarchy() { return RoleHierarchyImpl.fromHierarchy( "ROLE_ADMIN > ROLE_DB\n" + "ROLE_DB > ROLE_USER\n" + "ROLE_USER > ROLE_ANONYMOUS"); }

로그인

formLogin(Customizer.withDefaults())를 사용하면 /login 경로와 /login 페이지에서 하는 POST 요청 /loginProcessingUrl은 permitAll() 같이 동작을 하는듯합니다

로그인 후 리다이렉트

코드를 그대로 하셨다면 /api/login 경로로 요청을 하면 쿼리 스트링에 값이 없어도 CustomAuthenticationFilter는 토큰을 받게됩니다CustomAuthenticationProvider가 무조건 UsernamePasswordAuthethenticationToken을 반환하기 때문->CustomAuthenticationFilter 상위 클래스인AbstractAuthenticationFilter에서는 CustomProvider에서 넘겨준 Authentication 객체를 받았기 때문에 successfulAuthentication메소드가 동작하고 ->SavedRequestAwareAuthenticationSuccessHandler에서는 SavedRequest 객체가 없어서SavedRequestAwareAuthenticationSuccessHandler상위 클래스인 SimpleUrlAuthenticationSuccessHandler호출 ->최종적으로 AbstractAuthenticationTargetUrlRequestHandler에서 sendRedirect 합니다그럼 / 경로로 정상적으로 리다이렉트 됩니다정리하면 별도의 설정이 없으면 SavedRequestAwareAuthenticationSuccessHandler가 만들어지는데 여기서 / 경로로 리다이렉트 합니다

Spring Security 의 ProviderManager (AuthenticationManager) 도 옵저버 패턴을 사용하고 있다고 볼 수 있을까요?

해당 코드는 책임 연쇄 패턴에 더 가깝지 않을까요?

undo 메소드 작업중에서

제가 생각하는 light.on() 같이 Reciver의 메소드를 직접 호출하는 게 아닌 반대 성격의 command에게 위임하는 행위의 장점은 변경이 더 최소화 된다는 것 같습니다.light.on() API의 시그니처가 변경되면 기존 LightOffCommand의 undo 기능이LightOnCommand의 execute를 통해서 실행되기 때문에 LightOnCommand의 execute()만 변경하지만직접 on()을 호출하면 담당하는 Command와 반대 성격의 Command undo 부분 2가지 모두 변경해야 하기 때문입니다.

volatile 사용 이유에 대해서 여쭤보고 싶습니다!

이중 검사에서 synchroized 키워드로 원자성을 확보하고 이후에 접근하는 스레드들이 성능 이슈가 없게 하려고 맨 앞에 if(instance == null) 코드를 사용하는 건데 instance 변수에 대한 가시성이 확보되지 않아 이미 초기화되었는데도 synchroized 블록에 진입하여 성능 이슈가 생길까봐 volatile 키워드를 붙여 가시성을 확보한다. 저는 이렇게 이해했습니다

OncePerRequestFilter 질문

OncePerRequest가 아닌 일반 필터가 아닌 상황 request -> was -> 필터 -> 디스패처 서블릿 -> 컨트롤러 -> 서비스 에러 발생 throw Exception -> 이때 was는 error를 확인하고 error 페이지를 랜더링(forward)하기 위해서 다시 서블릿까지 보냄 결론 필터 2번 거침 was 까지 응답이 갔다가 다시 (일반)필터를 거치는 case 2가지 response.sendError / Uncaught Exception -------------------------------------------------- 강사님한테 질문 !!oncePerRequest가 한번만 필터링 되었는지 식별하는 로직이 복잡한듯한데 이렇게 복잡한 이유는 제가 설명한 에러 상황 이외에도 다른 케이스가 있을 거라고 추측을 합니다에러 상황이라고 하면 was는 attribute에 error를 넣어주니 간단하게 attribute를 확인해서 error 인지 확인하고 바로 넘기면 되니까요 다른 케이스를 하나 예시를 들어주실 수 있을까요?아님 제가 잘못 이해한 게 있을까요

Response 클래스

안녕하세요! 강의 재미있게 듣고 있습니다! 호돌맨님 답변중에 서비스에서 entity를 직접 Controller로 넘기지 않는 이유는Response로 변환할 때 뒤 늦은 entity의 참조를 방지하기 위해서 입니다.-> 이 이유는 연관관계가 있는 엔티티를 조회 시 지연로딩 때문이고 osiv를 false로 사용하기 때문일까요?

데이터 베이스 쿼리 실행 시점 관련 문의

AUTO_INCREMET 전략은 쓰지 지연 사용 안 하고 바로 INSERT 쿼리를 날려서 ID를 영속성 컨텍스트에 저장 SEQUENCE 전략은 INSERT 쿼리를 날리는 게 아니라 데이터베이스 시퀀스를 호출해서 ID를 영속성 컨텍스트에 저장하는 방식이어서 쓰기 지연 사용 근데 현재 강의에서는 AUTO 모드를 사용하는데 AUTO 모드는 AUTO_INCREMET, SEQUENCE, TABLE중에 하나를 각 DB 방언에 맞게 선택하는데H2 DB 같은 경우는 SEQUENCE를 사용하네요 로그를 보니까 실제로 SEQUENCE 호출 로그랑 DB에 시퀀스도 존재하구용 결론은 이번 케이스는 쓰기 지연을 사용하는 케이스입니다