Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

24-25-Server-Assugnment-06_정상화 #15

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

borntocode2
Copy link

Description

회원가입과 로그인 구현과 인가정보에 따라 API접근 권한을 다르게 설정하였습니다.

  1. JoinController를 통해 회원가입을 진행하면 /join과 /join/admin으로 user와 admin유저를 분리하였습니다.

  2. 로그인의 요청을 처리하는 SpringSecurity 필터는loginform을 disable함에 따라 사용을 못하기 때문에UsernamePasswordAuthenticationFilter를 커스텀한 LoginFilter에서 인가를 처리하게 됩니다.

  3. LoginFilter로 넘어온 사용자 정보는 authenticationManager의 authenticate 메서드에 의해 검증되며 검증에 필요한 UserDetailsService또한 커스텀을 진행하였습니다.

  4. 검증에 성공한 사용자 정보 객체는 SpringSecurity정의에 따라 UserDetails(CustomUserDetails)에 담겨 토큰을 생성하는 successfulAtuthentication메서드에 호출되며 JWT토큰을 발행받게 됩니다.

  5. 회원가입 경로에 따른 role값으로 게시판의 post들을 CRUD할 수 있습니다.

Important content

SpringSecurity가 /login요청을 처리하는 로직이 신기했습니다. 처음에는 /login요청을 받는 controller를 직접 구현했으나, 공식문서와 구글링을 통해 UsernamePasswordAuthenticationFilter는 정의에 따라서 /login 경로로 오는 POST 요청을 검증하게 되는 것을 알게 되었습니다. /login요청이 컨트롤러 단에 도착하기 전에 서블렛 필터들이 요청을 처리하여서 가시적인 로직의 움직임을 파악하는데에 시간 투자를 많이 하였습니다.

LoginFilter는 attemptAuthentication메서드를 통하여 사용자 정보를 탈취하고 authenticationManager의 authenticate메서드를 통하여 검증을 진행합니다. 검증에 성공할 경우 successfulAuthentication를, 검증에 실패할 경우 unsuccessfulAuthentication메서드를 실행하여 예외 처리를 진행하는 LoginFilter의 약속된 메서드들이 로그인 서비스를 구현하는데에 중점이라고 생각합니다.

role값을 어떻게 설정해야하는지에 대해서도 고민 했습니다. 데이터베이스의 role값을 임의로 수정할 수 있었지만, 조금 서비스적인 role 구현 방법을 택했습니다. 회원가입 요청은 /join과 /join/admin경로로 나뉘게 되는데, /join/admin요청을 했을 경우에 미리 정의한 adminKey와, /join/admin요청에 담길 JoinAdminDto의 adminKey필드와 일치하는지 검증하는 로직을 구현했습니다.

Question

  1. 이번 SESSION로그인 방식과 JWT로그인 방식을 공부하면서 가시적이지 않은 Spring 내부의 움직임(?)때문에 많이 힘들었는데, 이런 내부 동작 방식을 Spring docs에서 어떻게 서치하는지 팁이 궁금합니다..

  2. admin권한을 부여하기 위해 adminKey값을 미리 정의하고 요청에 담긴 dto의 adminKey와 비교하여 검증을 진행하였습니다. 해당 로직이 어설프다는 느낌을 받았는데, 이처럼 권한을 다르게 설정해줘야하는 경우에 일반적인 컨벤션이 있는지 궁금합니다.

Reference

  1. 김우진 코어 6주차 세션 - [https://velog.io/@woogym/GDGoC-JWT를-활용한-로그인-구현](https://velog.io/@woogym/GDGoC-JWT%EB%A5%BC-%ED%99%9C%EC%9A%A9%ED%95%9C-%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EA%B5%AC%ED%98%84)
  2. 개발자 유미의 JWT구현하기 시리즈- https://www.devyummi.com/page?id=668cff5ad3b43a6241eb6b6e
  3. 정상화 4주차 과제물 - https://github.com/borntocode2/24-25-Server-Assignment-04/tree/main/sanghwa

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant