bae jewoo

아래 비슷한 내용의 질문이 있었네요

뮤텍스 락

아 0부터 증가하는 걸 생각하지 못했네요

쿠폰 발급 개수 제한

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

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

<pre><code class="language-java">@Bean
public RoleHierarchy roleHierarchy() {
 return RoleHierarchyImpl.fromHierarchy(
 "ROLE_ADMIN > ROLE_DB\n" +
 "ROLE_DB > ROLE_USER\n" +
 "ROLE_USER > ROLE_ANONYMOUS");
}</code></pre>

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

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) 도 옵저버 패턴을 사용하고 있다고 볼 수 있을까요?

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

undo 메소드 작업중에서

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

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

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

bae jewoo

投稿