지난 포스팅에서 REST 방식의 로그인 요청에 대한 구현을 진행했었습니다.
이전 버전과 다르게 동작을 하지않아서 삽질을 조금 오래한 부분이 있는데,
다시 주기적으로 Security 에서 구현할 수 있는 기능들에 대해 점차 올려볼 예정입니다.
들어가기
오늘부터 구현될 클래스 및 기능들은 대부분 이전버전과 비슷할 수 있어서 다른 글을 찾아봐도 될것 같습니다.
로그인 성공 기본 동작
Form 로그인
Form 요청을 통한 로그인이 Security 동작의 가장 기본이 됩니다. 따라서, 현재 REST로 로그인 요청을 구현했지만, 아직 로그인 성공에 대한 구현을 하지 않았기 떄문에, 성공 요청 또한 Form 로그인을 했을 때 성공 로직으로 동작을 하게 됩니다.
Security의 내부 로그인 성공 로직
로그인 요청시 사용한 정보로 인증이 성공적으로 완료됐을 때, 이후 처리 로직이 동작하는데 여기서 this.successHandler 의 구현체가 SavedRequestAwareAuthenticationSuccessHandler 로 나타납니다.
실제로 AbstractAuthenticationProcessingFilter 에서 기본적으로 위 구현체를 선언해서 사용하고 있습니다.
SavedRequestAwareAuthenticationSuccessHandler
위 클래스의 메서드가 동작을 하게 되는데요, 기본동작 자체가 특정 페이지로 Redirect 를 하는 구조로 되어 있습니다. 따라서 우리가 원하는 결과와 관계 없이 Security 에서 지정한 페이지로 이동합니다.
Redirect 또한 기본으로 설정된 구현 클래스의 메서드로 동작을 합니다.
url 이 / 로 되어 있기 때문에, 우리가 요청한 로그인 동작은 최종적으로 / 로 이동합니다.
로그인 결과
로그인 결과를 보면 path 가 / 로 되어있으므로 정상적으로 / 를 요청한 것을 확인 할 수 있습니다.
직접 REST 로그인 성공 구현
로그인 성공에 대한 handler 클래스는 AuthenticationSuccessHandler 인터페이스를 구현하여 사용하고 있습니다. 따라서 우리가 구현해야할 인터페이스는 AuthenticationSuccessHandler 가 됩니다.
직접 구현한 로그인 성공 클래스
내부로직은 구현이 정상적으로 됐는지만 확인을 하기위해서 간단하게 구현했습니다.
인증객체를 로그로 확인하고, 성공 이라는 메세지를 전달합니다.
구현 클래스를 SecurityConfig & Custom Filter에 등록
직접 만든 AuthenticationSuccessHandler 를 설정하기 위해서 SecurityConfig 에 작성하고, 그 객체를 우리가 만들었던 Login Filter 가 사용할 수 있도록 설정합니다.
구현 이후 로그인 동작 확인
인증 이후 메서드에서 사용되는 this.successHandler 에 우리가 등록한 클래스를 사용하는 것을 확인 할 수 있습니다.
로그인 요청에 사용했던 정보가 정상 인증이 되어 인증객체가 로그에 정상적으로 나타났고,
/ 페이지에 대한 Redirect 요청이 아니라 메세지를 전달받게 됐습니다.
마치며
이번 글은 사실 다른 REST 로그인 구현글을 보시면 거의 일치하는 부분이 많았을거라서
크게 도움이 되지는 않았을겁니다.
이외에 로그아웃, 인증 실패(Entry) 등을 구현하는 방법은 다른 글에도 많이 있어서
굳이 글을 쓰지는 않겠지만, 따로 요청이 들어온다면 그 부분에 대한 구현도 올려보겠습니다.
다음은 요즘엔 거의 쓰지않는(?) 자동 로그인 구현에 대한 부분을 올려볼까 합니다.
써보신분들은 아시겠지만, 기본적으로 동작하는 로직과 유사하게 진행할 것으로 예상됩니다.
