<출처> 넷플릭스 수리남
에러만 나불나불대는 나의 프로젝트. 이번엔 또 무엇이 문제였는가?
사건의 발단
스프링 시큐리티를 적용했는데 UserDetailsService에 있는 loadUserByUsername 매서드가 쓰이지 않는 문제를 발견했다. 분명 완성했다고 생각했는데 혼비백산해서 다시 에러핸들링 시작.
해결1
회원가입, 로그인 로직을 사용하는데 왜 저 매서드가 콜링이 안되는것이지? 인증이 제대로 되지 않고있나? 생각해서 fromLogin의 문제인가? 무엇이 문제일까?를 계속 고민했다. 여러 시도를 했는데...
주석처리되어있던 formLogin이 원래 형태인데,(사용안하는) formlogin을 한번 사용해볼까?라는 생각으로 돌리게 된다. 그러나 저 패러미터 중 어떤 것을 사용해도 돌아가지 않았다. 심지어 loginProcessingUrl은 아래와 같은 기능이었다.
https://stackoverflow.com/questions/53140629/spring-security-loginpage-vs-loginprocessingurl
위 글에서 중요한점은
- loginProcessingUrl 은 antMatchers("/thisUrl").permitAll() 을 내장한다.
- "응답"을 리턴해야 한다. 우리는 프론트단을 만들지 않으므로 저건...안타깝다.
해결2
무슨 짓을 해도 안된다. 그래서 다시 강의자료를 보고, 내 코드를 한참 한참 들여다봤다. 결국 UserDetailsService가 UserDetails를 불러오고, 그 유저 디테일스가 쓰이는곳은 컨트롤러단이었던 것이다...
마음은 찢어지지만 덕분에 구조나 쓰임새에 대해 더 공부하게 되어서 다행이라고 생각이 된다.
알게 된 점
- 위 UserDetails가 정확히 어떤 곳에서 사용되는지
- 위처럼 addFilterBefore를 사용해 필터하겠다고 결정해주면 된다는 것. 그 필터는
dofilter를 통해 필터를 착착 해나가고, 시큐리티 콘텍스트 홀더(시큐리티 콘텍스트(어쎈티캐이션 객체))의 형태로 나아간다.
그리고 setAuthentication 매서드 안에 있는 createAuthentication에서는 이 어쎈티케이션 객체를 담은(인증된 사용자의 정보들, principal/credential/authorities) 토큰을 발행한다. 이 토큰이 다시 시큐리티 컨텍스트 홀더에 저장된다
결국 내가 사용한 UserDetails는...지쟈스. 아니 씨...저거 왜 토큰 만들어...진건데 쓰일대만 사용하지? 유저 만들 때 디테일 만들어져야하는거 아니냐?...뭐야대체
내일 알아보기로 하자.
