RestApiDsl 에서 rememberMeService가 처리가 되는데json 방식으로 통신 시 remember-me 파라미터를 받지못합니다. AbstractRememberMeServices 를 상속받아 따로 처리해야 하는 건지 궁금합니다.  

현재 지금 프론트와 백엔드로 나누어져 웹 개발을 하고 있습니다 여기서 궁금한점은 선생님 코드를 다 따라 적었는데 프론트에서 로그인 요청을 해서 로그인한 이후 프론트에서 메인 페이지로 보내는데 거기서 다음 기능을 쓰려고 하면 서버 500에러가 뜨고 어나니머스필터가 요청을 받는거 같습니다 저도 정확하게 알 수 없어서 그런데 혹시 CSRF기능을 안써서 어나니머스필터로 가는 것인지 아니면 뭐가 잘못 된건지 알 수 없습니다 좀 알려주시면 감사하겠습니다

Rest 방식 로그인 하였을 때 유저정보를 불러오지를 못합니다.로그인 하였을 때 로그 filerChainrestFilterrestcontroller@AuthenticationPrincipal 에 담긴 정보 

RestAuthenticaionToken 클래스를 만든 의미가 궁금하고 여기 시큐리티에서 token의 의미가 무엇인지 궁금합니다

동시성준비중이신다음강의는뭐에요?

T7. 개인정보보호법 시행령 개정 강의개인정보 보호책임자 제도 개선_ 개인정보 보호책임자 독립성 보장 및 협력체계 T6. Add-on 토픽 강의정보통신서비스 개인정보보호 ▶ 앱 푸쉬 (App Push) 광고 두개의 영상이 같습니다.수정부탁드립니다.

안녕하세요. 선생님시큐리티 강의를 재밌게 듣고있는 한 학생으로서 명품강의를 만들어주셔서 감사드립니다. 강의를 들으면서 SameOrigin과 쿠키(SameSite)의 차이를 구별할 수 있게 됐고 더 나아가 Samesite간의 SingleSignOn(sso)이라는 기술도 관심을 갖게 됐습니다.  sso관련하여 추천하실만한 도서나 기술블로그가 있으신지 궁금합니다~!

로그인의 경우 앞선강의에서 /login 엔드포인트로 post요청을 보낼텐데, 지금 예제를 보면 모든 엔드포인트에 대하여 HttpMethod.POST는 ROLE_WRITE권한을 가져야한다라고 명시되어져 있습니다.MANAGER권한을 갖은 UserDetails 계정으로 로그인을하면 post요청을 보내니 로그인이 실패되지 않을까 고민이 되었는데, 성공하는 것을 강의에서 확인하였습니다. 이것이 왜 가능한 것인지 궁금합니다.

인증제공자 2에서 커스텀한 필터 적용하고 마지막으로 서버 가동후에 테스트 하는데 해당 화면이 뜹니다.주소창에 localhost:8080 입력후 접근하면 제대로 뜨는 것을 보면 리다이렉트 문제라고 생각되는데쿼리스트링으로 인증 후에 다시 루트로 리다이렉트를 어떻게 해야 하나요?다 옮겨 적은 거 같은데 혹시 제가 놓친 설명이나 코드가 있다면 죄송합니다.  

스프링 시큐리티 6.0 강의를 구매했는데요. 혹시 이전강의 스프링시큐리티 Auth를 안들어도 괜찮은지 궁금하네요. 인트로 보고 있는데, 이전강의 얘기 하셔서, 혹시 이전강의 봐야만 하는지..

AuthenticationManager가 부모 AuthenticationManager를 가지는 이유를 모르겠습니다. 매니저는 프로바이더를 여러 개 가질 수 있는데, 굳이 부모 매니저를 추가로 가질 수 있도록 해서 부모의 프로바이더를 사용해야할 이유가 있을까요? 그리고 그렇게 사용하는 적절한 예시가 있을까요? 

안녕하세요기출문제풀이 과정이 포함되어 있다고 명시되어 있는데 어디서 확인 가능 할까요?

DSLs 검색해보니 도메인 특화 언어로 주로 나오던데 해당 뜻으로 사용되는게 맞는지 궁금합니다 ㅎ

문제풀이 과정 혹은 자료있으면 공유가 가능할까요 ?kgm0178@naver.com 

안녕하세요.기억하기 인증 필터(RememberMeAuthenticationFilter) 강의를 듣다가 사소한 궁금증이 생겨 질문드립니다. 리멤버미 쿠키를 사용시 쿠키를 바탕으로 인증 정보를 가져오는 로직에서, JSESSIONID 쿠키가 만료되었을 때와 서버가 재시작되었을 때 password가 왜 다르게 불러와지는지 알고 싶습니다. 서버 재시작 시 리멤버미 쿠키로 인증 정보가 복구되지 않는 이유를 조사하던 중에 생긴 의문인데요. 제 생각으로는 쿠키에 인증 정보를 담고 있어서, 서버가 재시작되더라도 쿠키가 만료되지 않는 한 인증 정보를 복구할 수 있을 것 같았거든요. 제가 코드를 따라가서 확인한 부분은..리멤버미 쿠키를 생성할때 맨 마지막 필드로 makeTokenSignature 메서드의 값이 들어가는데 이 값은 String data = username + ":" + tokenExpiryTime + ":" + password + ":" + getKey(); 정보를 조합하여 만들어지는데,여기서 getKey()는 RememberMeConfigurer에서 init할때 rememberMeServices를 커스텀하게 주입하지 않으면RememberMeConfigurer에서 UUID.randomUUID().toString()로 가져오기 때문에 서버가 재시작할때마다 랜덤한 값을 가지고 오더라구요. 그래서 서버가 재시작되더라도 고정된 key값을 사용하기 위해 TokenBasedRememberMeService를 생성하여 아래와 같이 설정하였습니다.이후에 getKey()할때도 key로 test를 가지고 오는것을 확인하였구요. 그러면 이제 key가 고정이기 때문에 서버가 재시작되어도 리멤버미 쿠키를 바탕으로 인증을 진행하여 로그인 없이 세션이 유지될줄 알았는데?!, processAutoLoginCookie 메서드에서 아래 코드에서 exception이 발생합니다.. if (!equals(expectedTokenSignature, actualTokenSignature)) { throw new InvalidCookieException("Cookie contained signature '" + actualTokenSignature + "' but expected '" + expectedTokenSignature + "'"); } 확인해보니 유저 정보를 가져올때 password를 다르게 가져오고있더라구요. TokenSignature는 password와 여러 정보를 조합하여 만드는데, password값이 달라지니 예상값과 실제값이 차이가 나서 exception이 떨어지구요.. UserDetails userDetails = getUserDetailsService().loadUserByUsername(cookieTokens[0]);*로그인 > JSESSIONID 삭제 이후 로그인시*서버 재시작 이후 로그인시 질문이 좀 장황했는데, 왜 password를 다르게 가져오는지 궁금합니다. 코드를 쫓아가다가 길을 잃어서 도움을 받을수 있을까 하여 질문을 남겨요.. 감사합니다.

안녕하세요. 스프링 시큐리티 완전 정복 6.x 버전 잘 들었습니다.궁금한 점 이 있는데요.세션 클러스터링을 통해서 redis를 적용하면 세션이 tomcat -> rediss로 변경되는 부분 확인하였고, 잘 동작되는 것도 확인하였습니다.궁금한 점은 단일 서버일 때 중복 로그인 설정을 하면 session 체크를 ConcurrentSessionFilter에서 하는 것으로 알고 있는데, 세션 클러스터링을 적용하면 동시 세션을 어떻게 체크하는지 궁금하고, 이것을 제어하기 위해 설정이 추가로 필요한지 궁금합니다.단일 서버일 경우 sessionManagement를 통해서 maximumSessions(1) 인 것을 체크를 하게 되는데, 세션 클러스터링을 적용할 경우 이 값을 어떻게 공유하면서 처리하는지 궁금합니다.감사합니다.

강의 13분 50초를 보면this.securityContextHolderStrateget.setContext(context);this.securityContextRepository.saveContext(context, request, response);두 메서드가 존재합니다.전자는 ThreadLocal에 인증객체를 저장한다라고 하셨고,후자는 세션에 저장한다라고 설명해주셨는데 개인적으로 잘 이해가 안갑니다. 차이가 무엇인지...

리프로그래밍 강의에 이어 사이버보안 강의도 잘 듣고 있습니다~ 감사해요!Autosar 강의를 너무 고대하고 있는데(NM쪽이 너무 궁금해서요), 일정이 살짝 딜레이 된 건가 해서요! 언제 업로드될지 궁금합니다! (바쁘신 와중에 강의도 찍으시구 대단하신 거 같습니다!)

강의자료 95 page에는 커스텀 한 인증 필터를 구현할 경우 securityContext.saveContext()를 명시적으로 작성해야 된다고 적혀있는데 해당 부분은 OncePerrequestFilter 를 통해 완전 처음부터 작성한 커스텀 필터일 경우이고 이번 강의에서는 AbstractAuthenticationProcessingFilter를 상속받고 그 내부에서 successfulAuthentication 을 통해서 saveContext() 가 작동한다고 이해했는데 맞을까요?

저번시간에 커스텀 UserDetailsService를 만들고 이번에 커스텀 AuthenticationProvider를 만드는데 커스텀 AuthenticationProvider는 왜 만드는건가요? 커스텀 UserDetailsService는 저희가 이번 프로젝트에서 유저 객체를 db와 연동하기 때문에 구현을 안하면 제대로 작동하지 않아서 반드시 만들어야 하는데, 커스텀 AuthenticationProvider는 만들지 않아도 저번시간마지막에 보면 로그인 인증이 제대로 되는데 왜 만드는건가요?