Naver Login시 권한에 대해 질문이 있습니다

네이버에서 access token 응답으로 scope를 안 넣어주네요...keycloak, google은 넣어주는데 말이죠.실제 액세스토큰을 갖고오는 부분에서 응답의 scope를 읽고 액세스토큰 객체를 생성하고이 scope들을 기반으로 OidcUserSErvice든 DefaultOAuth2UserSErvice든 scope 값을 사용해서 권한을 만드는데 그 과정에서 권한이 하나도 만들어지지 않기 때문에 문제가 생긴것 같습니다.

Controller에 Authentication타입 파라미터를 주입하는 HandlerMethodArgumentResolver의 구현체가 무엇인가요?

저도 이게 궁금해서 디버거를 걸어봤는데요public class HandlerMethodArgumentResolverComposite implements HandlerMethodArgumentResolver { private final List argumentResolvers = new ArrayList(); @Override @Nullable public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer, NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception { HandlerMethodArgumentResolver resolver = getArgumentResolver(parameter); if (resolver == null) { throw new IllegalArgumentException("Unsupported parameter type [" + parameter.getParameterType().getName() + "]. supportsParameter should be called first."); } return resolver.resolveArgument(parameter, mavContainer, webRequest, binderFactory); } 디스패처 서블릿에서 HandlerAdapter 로 핸들러 처리를 위임하고(RequestMappingHandlerResolver) 쭉 타고 가다보면HandlerMethodArgumentResolverComposite 로 올 수 있습니다. 우리 메서드의 arugment를 실제 resolve 하는 argument REsolver가 나오는 지점에 breakpoint를 걸고 확인해봤어요.public class ServletRequestMethodArgumentResolver implements HandlerMethodArgumentResolver { @Override public boolean supportsParameter(MethodParameter parameter) { Class paramType = parameter.getParameterType(); return (WebRequest.class.isAssignableFrom(paramType) || ServletRequest.class.isAssignableFrom(paramType) || MultipartRequest.class.isAssignableFrom(paramType) || HttpSession.class.isAssignableFrom(paramType) || PushBuilder.class.isAssignableFrom(paramType) || (Principal.class.isAssignableFrom(paramType) && !parameter.hasParameterAnnotations()) || InputStream.class.isAssignableFrom(paramType) || Reader.class.isAssignableFrom(paramType) || HttpMethod.class == paramType || Locale.class == paramType || TimeZone.class == paramType || ZoneId.class == paramType); }ServletRequestMethodArgumentResolver 여기서 파라미터에 어노테이션이 없는 Principal 을 잡아 처리하네요!else if (Principal.class.isAssignableFrom(paramType)) { Principal userPrincipal = request.getUserPrincipal(); if (userPrincipal != null && !paramType.isInstance(userPrincipal)) { throw new IllegalStateException( "Current user principal is not of type [" + paramType.getName() + "]: " + userPrincipal); } return userPrincipal; }resolveArgument 메서드에 가보면 request(요청객체) 에서 getPrincipal 을 하고 그것을 반환하는 구조로 되어 있네요.그리고 작성자님께서 언급하신SecurityContextHolderAwareRequestWrapper 쪽에 가보면 private Authentication getAuthentication() { Authentication auth = this.securityContextHolderStrategy.getContext().getAuthentication(); return (this.trustResolver.isAuthenticated(auth)) ? auth : null; }이 request 객체가 securityContextHolderStrategy 를 통해 authentication 을 찾아 반환하는 구조로 되어있어요.

강사님 몇일동안 구글 검색만 100개 했는데도 이유를 모르겠습니다..

https://www.inflearn.com/questions/1062616/%EC%B5%9C%EC%8B%A0-%EC%8A%A4%ED%94%84%EB%A7%81-%EC%8B%9C%ED%81%90%EB%A6%AC%ED%8B%B0-ajax-%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EC%8B%9C%EB%8F%84-%EC%8B%9C-%EC%BF%A0%ED%82%A4%EA%B0%80-%EC%98%A4%EC%A7%80-%EC%95%8A%EC%9D%84-%EB%95%8C-%EC%82%BD%EC%A7%88-%EA%B8%B0%EB%A1%9D전에 제가 삽질한 기록이 있는데 이글 보시면 될 것 같아요

private final ObjectProvider<Mylogger> myLoggerProvider

(사진) (사진) - MyLogger 생성시 @RequiredArgsConstructor 어노테이션을 클래스에 달았으므로 생성자가 자동으로 생성됩니다. (실제 컴파일 후 class파일에서는 생성자가 추가되어 있음) - 생성자가 하나뿐일때는 별도로 @Autowired 어노테이션을 붙이지 않아도 자동으로 의존성 주입이 됩니다. (사진) (사진) 메인(SpringBoot 시작부)을 실행하면 우선 컨테이너를 생성하고 컴포넌트 스캔을 합니다. 이 과정에서 Configuration을 비롯한 빈들이 쭈르륵 생성되겠죠? @Service 어노테이션도 내부적으로는 @Component 어노테이션이 있으니 컴포넌트 스캔의 대상이 됩니다. (순수 자바에서는 어노테이션의 상속같은 개념이 없지만, 스프링에서 관리되는 어노테이션들은 이렇게 내부적으로 붙어있는 어노테이션을 참조하는 것으로 알고 있습니다.) 이렇게 싱글톤 빈들이 생성됩니다. 이 생성과정에서, LogDemoService의 생성자를 호출하는 과정에서 의존관계에 해당하는 다른 빈들도 생성해서 주입하게 됩니다. 이때는 스프링 내부적인 로직에 의해서 ObjectProvider 인터페이스의 구현체가 생성되어 주입될겁니다. 이때 MyLogger의 빈 스코프는 request 스코프를 따르므로, 생성되지 않습니다. 이후 빈들의 의존관계가 주입되고 빈 초기화들이 일어나고... 스프링 웹 어플리케이션이 정상적으로 실행이 됩니다. 이제 http에서 log-demo 요청이 들어옵니다. (사진) controller에 request가 들어오고, myLoggerProvider에게 MyLogger 빈을 요청합니다. MyLogger이 없습니다. 이 때 myLoggerProvider는 request에 대응하는 MyLogger을 컨트롤러에게 요청하고 컨트롤러는 이를 생성하고, 빈 스코프에 맞게 요청이 끝날 때까지 이 빈의 라이프 사이클을 관리해줍니다. ---- 저도 이 부분을 학습하고 있는데 제가 이해하고 있는 것을 기반으로 답변해봅니다... 틀릴 수 있으니 양해 부탁드립니다.