1) 로그인 구현
POST 방식 사용하는 이유 : 소중한 유저 정보를 주소창에 노출하면 안되기 때문에 예외적으로 로그인만 사용한다.
로그인은 별도의 컨트롤러를 만들지 않고 아래처럼 시큐리티설정파일에서 스프링 시큐리티를 이용해 로그인 프로세스를 진행한다.
29줄의 권한이 없는 유저가 접근을 할 때 로그인 페이지로 자동으로 가게 하는 것과 30줄의 로그인 프로세싱은 GET, POST 이렇게 방식이 다르기 때문에 url이 같아도 괜찮다.
UserDetailsSerivce는 SecurityConfig /auth/signin의 url에서 POST 방식으로 가져온 username과 password를 가지고 로그인을 진행한다.
로그인 프로세싱을 위해서 UserDetailsSerivce를 상속 받은 서비스를 만드는데, 이 서비스에 @Service를 붙이게 되면 기존 Ioc에 등록되어 있던 UserDetailsSerivce를 대체하게 된다.
2) DB에서 같은 유저네임이 있는지 찾아보는 과정
- 패스워드는 시큐리티가 알아서 체킹 (12줄)
- 리턴이 잘 되면 자동으로 UserDetails 타입을 세션으로 만든다.
리턴 타입을 UserDetails 으로 해야하는데 UserEntity를 담아야 하므로, UserDetails를 상속한 PrincipalDetails를 만들어서 대체한다.
(34~60줄은 false 이면 로그인이 안된다. 개인정보보호법에 의한 정보 파기 등에 대한 서비스이다.)
람다식을 사용해서 함수를 넘겨주기
3) 로그인 후 화면 띄우기
9줄 : GetMapping에 여러개를 쓰고 싶으면 중괄호{}를 넣어서 추가할 수 있다.
사용자 개개인의 프로파일사진 등을 보여주기 위해서 {id}를 넣음
16줄 : int id를 매개변수로 넣기 위해 @PathVariable 사용
4) 세션 접근하기
로그인 과정으로 설명해보자면
POST 방식 /auth/signin >> 서버 앞단의 시큐리티 (내부의 PrincipalDetailsService >> username 확인)>> 없으면 아웃/ 있는 경우, PrincipalDetails를 세션에 저장함.
이때, Session 영역 안의 SecurityContextholder 에 PrincipalDetails를 Authentication에 넣어서 저장함.
이말인 즉슨, 세션에 접근해서 user의 정보를 가져오려면
Session - SecurityContextholder - Authentication - PrincipalDetails 의 과정을 거쳐서 가져와야 하는데 너무 복잡함! 극혐!
그래서 스프링부트에서는 @AuthenticationPrincipal 이라는 어노테이션을 이용하면 간단한 코드로 가져올 수 있음.
어노테이션 없이 가져올 때, 얼마나 길고 복잡한지 알 수 있다.
