질문&답변
스프링 시큐리티가 빈으로 등록했을 때 추가하는 원리는 빈이 한개일 경우, 빈이 두개일 경우에 따라 다르게 구성됩니다. 강의에서 여기에 대한 자세한 설명을 하고 있습니다. 다만 캡쳐하신 이미지처럼 시큐리티가 구성한 부분은 특정한 원칙을 이해하기 보다는 빈 등록에 따른 결과의 패턴을 그대로 이해하고 사용하시면 됩니다 저도 여러 경우의 상황을 테스트 해 보면 왜 프로바이더가 이런 식으로 구성이 되는지 이해가 잘 안되는 부분들이 있더군요 그래서 직접 빈을 등록하면서 어떻게 구성되는지 확인하고 적절하게 사용하시면 됩니다. 제가 강의에서는 몇가지 예를 들면서 설명을 하고 있지만 여전히 명확한 규칙, 원칙이 있다 라고 이해하기 보다는 이런 경우에는 이렇게 되고 저런 경우에는 저렇게 되는구나 라고 이해하는 정도입니다. 그러니 그 부분은 원리를 깊게 생각하지 않아도 될 것 같습니다.
질문&답변
아래 내용을 참고하시면 되구요 스프링빈은 기본적으로 싱글톤이라 여러번 호출해도 이중 생성이 되지는 않습니다 말씀하신 것처럼 빈으로 주입받으셔도 됩니다 @Component 로 선언하시면 됩니다
질문&답변
예를 들어 아래와 같은 속성을 설정한다고 했을 때 맨 아래에 userNameAttribute: preferred_username 를 추가해 주세요 keycloak 은 기본적으로 userNameAttribute 속성에 preferred_username 를 찾습니다. keycloak: issuerUri: http://localhost:8080/realms/oauth2 authorizationUri: http://localhost:8080/realms/oauth2/protocol/openid-connect/auth jwkSetUri: http://localhost:8080/realms/oauth2/protocol/openid-connect/certs tokenUri: http://localhost:8080/realms/oauth2/protocol/openid-connect/token userInfoUri: http://localhost:8080/realms/oauth2/protocol/openid-connect/userinfo userNameAttribute: preferred_username
질문&답변
400 오류는 클라이언트 오류라 서버로그가 나오지 않아 원인을 정확하게 알기가 어렵습니다. 예를 들어 요청을 보내는 파라미터 정보중에 서버에서 정한 규약이나 값의 타입 등 맞지 않거나 누락되거나 등의 문제들이 잇습니다. 강의에서 설명하는 부분에서 어떤 부분이 차이가 나는지 좀 더 세밀하게 보시길 바라며 힌트를 얻을만한 오류 메시지나 로그가 잇다면 첨부해 주시면 원인을 찾는데 도움이 될 것 같스니다
질문&답변
네 https://github.com/onjsdnjs/spring-batch-lecture 에 있습니다 각 브랜치별로 있습니다
질문&답변
네 맞습니다. 기본적으로 로그인 페이지와 로그아웃 페이지를 생성하도록 초기화 때 생성되는 필터라 보시면 됩니다.
질문&답변
코드는 강의 버전으로만 제공됩니다. 참고로 저의 스프링 시큐리티 6.x 완전정복에서 3.xx 버전으로 제작되어 있습니다.
질문&답변
사실 시큐리티가 세션을 저장하는 메커니즘을 내부적으로 하고 있기 때문에 트랜잭션이나 예외처리 관련해서는 별도로 커스텀하게 해 보지는 않았습니다 수동으로 직접 핸들링하는게 아니기 때문에 제약이 잇긴합니다 그런데 세션저장에 있어 롤백처리가 되면 세션을 저장하지 않겟다는 의미인가요?
질문&답변
아 죄송하지만 대략 어디 위치인지 알 수 있을까요
질문&답변
기본적으로 생성되는 provider 이 daoprivider 와 basicprovider 이고 remembermeprovider 는 rememberme 설정이 있을때에만 생성됩니다 이때 커스텀한 provider 를 등록하면 dao 와 basic 는 제외됩니다 강의에 자세히 설명하고 있습니다 네 결론은 그렇습니다. Providermanager 생성은 별도의 인증을 분리해서 사용하고자 할 때 활용할 수 있습니다 기존의 manager는 그대로 존재합니다 그래서 시큐리티에서 제공하는 form 인증은 기본적으로 제공하는 manager 를 사용하고 별도의 rest 방식의 인증은 새로운 manager 에서 사용하도록 구성할 수 있습니다 두 manager 는 서로 간섭하지 않고 각 인증방식에 맞게 동작하게끔 할 때 사용하시면 됩니다
