저번 간단했던 인증인가에 추가적으로 기능 구현을 하게 되었다.
AWS 로그인 정책
AWS 를 이용할때는 크게 두가지 로그인 방법이 있다.
ROOT 사용자, IAM 사용자
정확하게는 모르지만 Root 계정을 만들고 이 ROOT 계정을 통해 IAM 이라는 하위 계정을 생성할 수 있다.
이러한 정책을 우리 프로젝트에서도 적용하자는 의견이 나와서 기존에 만들었던 인증/인가 부분을 바꿔서 적용했다.
SignUp
회원가입의 경우 원래있던 코드를 그대로 사용했다.
계정은 두 분류지만
회원가입을 하는 계정은 Root 계정밖에 없기때문!
IAM 계정은 Root 계정이 만들어줘야지만 생성되게 된다.
CreateIAMAccount
IAM 계정을 생성하는 메소드이다.
내가 구현한 jwt 토큰에는 사용자의 role이 claim으로 들어가게되는데
이 role을 파싱해서 권한을 조회하고 권한이 role_root 인 경우에만 해당 메소드를 호출할 수 있다.
LogIn
로그인은 두 메소드 모두 같은 동작을 수행한다.
하지만 Root user, IAM user가 회원가입을 할 때 던져주는
request와 호출 후 받는response의 형태가 서로 달라 원래 있던user도메인을 두개로 분리하면서 메소드 또한 두개로 나눠놨다.
GetAllMembers
모든 사용자를 조회하는 메소드이다.
이 메소드 또한 root 계정만 호출할 수 있으며, 본인이 만든(createIAM) 계정들만 조회할 수 있다.
구현 중 두가지 고려사항이 있었다. 😵
1. ROOT만 할 수 있게 어떻게 할 것 인가?
첫번째 고려사항은 위에서 createIAM 권한을 부여하는 것과 동일한 방법으로 해결했다.
현재 로그인한 사용자의 jwt를 까보고 role을 확인해 role이 root일 경우 메소드 호출이 가능하다.
2. 자기가 만든 IAM인지 어떻게 알 것 인가?
IAM user 의 필드 중 groupId를 넣어줬다.
로그인한 사용자의 id로 groupId를 초기화해서 추후 본인의 id를 groupId로 한 user를 모두 조회하면 됐다.
@ControllerAdvice
이전글에서 하려고 했던 controllerAdvice를 적용했다.
전에는 bindingResult를 파라미터로 받아 컨트롤러에서 메소드단위로 처리해서 똑같은 코드의 중복이 많아졌다.
GlobalExceptionHandler를 적용하면서 ContollerAdvice 어노테이션을 사용해봤는데 이렇게하면 Controller단에서 생기는 오류를 이 예외 클래스가 먼저 낚아채서 확인한다. -> 코드의 중복이 적어진다!
코드리뷰 👍
이번에도 구현 후 팀원들에게 코드에 대한 리뷰를 받았다.
- api path들을 restful apis 규칙에 맞게 리팩토링 해보는 것을 제안
작명에 대한 리뷰는 처음이였다. 그래서 restful apis 작명 규칙에 대해 알아보았다.
꽤 여러가지 권장되는 네이밍 규칙들이 있었는데, 내가 적용해야 할 부분은 다음과 같다.
-
crud 함수명을 사용하지 마라.
url은 주체가동작이 아니라 resource 즉,자원에 있다.
한 자원에 대해 다른 동작은 http method를 통해 알 수 있게 해야한다고 한다. -
필터를 위해 쿼리파라미터를 사용해라.
같은 동작을 하더라도 다른 기능에 더 도움이되는 구현이 수고를 덜 하게 될 것 같다.
- 내/외부 api를 좀 더 분명하게 분리해서 내부 api 일경우에는 조금 더 가벼운 방식으로 데이터를 교환해도 될 것 같다는 조언
내 feign에 정의 되어있는 메소드들이다.
user와 auth에서만 사용되지만 ResponseEntity로 모두 묶여있는 형태이다.
ResponseEntity는 상태 코드와 헤더를 포함하는 복잡한 객체이므로, 필요한 정보만 담고 있는 DTO를 사용하면 더 간단하고 빠른 통신이 가능해질 것 같다.
앞으로
이제 인증/인가와 관련된 부분은 어느정도 끝이났다.
이제 결제와 관련된 부분을 구현해야 한다. 화이팅 !
