• 카테고리

    질문 & 답변
  • 세부 분야

    백엔드

  • 해결 여부

    미해결

Adaptor 패턴의 사용 (UserAccount)

21.06.03 16:00 작성 조회수 224

1

안녕하세요 기선님! 어느덧 기선님의 강의를 다 들어보고, 다시 구체화하고 있네요.

항상 양질의 강의 감사합니다!! :)

기선님께서 @AuthenticationPrincipal 애노테이션을 통해서 authentication의 principal 정보를 가지고 올 수 있다고 하셨습니다!

그래서 저는 principal의 값으로는 닉네임 같은 String값을 사용하거나, 이외에는 UserDetails 인터페이스를 구현한 클래스( 여기서는 User 클래스를 상속받은 UserAccount)만 principal 정보로 사용가능한 것인가 생각을 했습니다. 

여러 경우를 시도해보다가 위의 조건에 해당되지 않은 단순한 도메인 account 객체를 principal로 주고 @AuthenticationPrincipal을 통해서 바인딩을 받아보았는데, 인증이되지 않은 경우에는 null, 인증이 된 경우에는 해당 account 객체를 바인딩 받을 수 있었습니다.

마지막 결과는 인증하지 않았을때는 null,  인증이 되었을 때는 바인인 받은 acconut의 닉네임 값을 출력한 것입니다.

UserAccount 패턴을 사용하지 않아도 동일한 결과를 얻을 수 있어서 질문을 드렸습니다!!

아니면 이렇게 principal로 도메인 클래스의 객체를 주는 방법이 정석적인 방법이 아닌걸까요?

감사합니다 :)

답변 2

·

답변을 작성해보세요.

2

김세진님의 프로필

김세진

질문자

2021.06.04

기선님 계속해서 진행해보다가 질문을 드립니다! 

기존의 form 입력값으로 로그인을 하는 과정에서는 시큐리티 인증 처리 과정에 의해서  UserDetailsService의 loadUserByUsername 메서드의 리턴값인 UserDetails의 구현체로 인증을 하게되는데,  제가 사용한 방식은 자동 로그인의 경우 account를 principal로 사용하였습니다.

그렇기 때문에 자동 로그인에 의해서 인증이 된 사용자는 @AuthenticationPrincipal을 통해서 account를 바인딩 받을 수 있었지만, form 로그인으로 인증이 된 사용자는 직접적으로 account를 바인딩 받을 수 없었습니다.

그래서 이를 동일하게 맞춰주기 위해서 UserAccount 클래스를 사용한다고 보면 되는 것인가요?

기선님이 말씀해주신 account와 시큐리티의 UserDetails의 간극이라는 것이 이것이 맞는지 궁금합니다!!

0

네 그게 맞아요. 인증 방식에 따라 principal에 들어가는 객체가 달라질 수 있는데 그 안에 들어가는 정보와 우리가 만든 도메인(Account)의 정보를 맞춰주려다보니 그런 패턴을 쓰게 되더라구요.

김세진님의 프로필

김세진

질문자

2021.06.04

그렇군요! 감사합니다 :)