개요
스프링 시큐리티에는 @PreAuthorize 와 같은 어노테이션이 존재한다. 이 어노테이션은 인증과 인가를 편하게 해주는데,
예를 들어 @PreAuthorize("hasRole('ROLE_USER')") 와 같은 식으로 사용해서 간단하게 인가를 할 수 있게 만든다.
-
나는 아직 스프링 시큐리티를 배우지 못했지만, 현업에서 사용하는 방식과 최대한 유사하게 프로젝트를 만들어보고 싶었다. 이 점에서 나는 이미 기능으로서는 완성된 프로젝트에 몇가지 개선을 하기로 결심했다. 다음과 같은 기준을 가지고.
문제점들
- 기존 프로젝트는 서비스 부분에서 인증/인가를 모두 수행했다. 이와 같은 방식은 서비스 안에 있는 매서드 하나하나의 독립성을 헤친다. 객체지향적 관점에서도 하나의 매서드는 하나의 역할만을 가져야 하기 때문에, 이 부분에 대한 해결이 필요했다.
위의 사진처럼 인가에 대한 if문이 서비스 매서드 안에 들어있었다. 이는 Service 로직 안에서의 불필요한 반복을 하게 만들고, 더하여 Service에서 해야 하는 역할인 비즈니스 로직에 대한 수행도 아니다.
-
컨트롤러 단에서 유저 객체가 필요한가? 라는 물음이 있었다.
이와 같이 객체 자체를 불러와서 참조하는 형식은 불필요하다. User 안에 있는 특정 정보, 위 updateComment 매서드에서는 단지 유저의 이름만 필요했을 뿐이다.
해결책
- 변경 전의 모습
-
변경 전 프로젝트에서 CheckUtil은 단지 토큰 검증과 인증만을 수행했다. 그러나 이 부분에 인가에 대한 부분, Authorization에 대한 부분을 추가하는 것이 좋겠다고 생각했고, 실행했다. 더하여 토큰 체커가 User를 직접 반환하지 않도록 변경했다.
여기서 원래는 인증된 토큰만 얻을 수 있었는데, user에서 Role을 가져오도록 변경했다. 그렇다면 UtilDto에서는 어떤 값을 사용해야 할지 알 수 있게 된다. 매서드에서 사용자 체크를 위해 필요했던 userName과, userRole만 포함하면 된다.
위와 같이 정적 팩토리 매서드를 사용해 UtilDto가 User 안에 있는 name,Role을 사용 할 수 있도록 변경했다.
- 위와 같이 UtilDto를 사용해서 Dto를 반환하게 된다면, Service 로직 안에서의 간결화도 가능하다.
위와 같이 변경이 가능했다.(아직도 조금 마음에 안들지만)
- 더불어 스프링 시큐리티 사용을 대비해서 ADMIN API와 USER API를 분리했다.
위와 같이 API를 나누어서 분리했다. 이를 통해 서비스 로직이 간결해지고, 어떤 매서드는 패러미터를 줄일 수 있었다.
결론
내가 이번 개인 프로젝트를 하면서 배운 점
-
Controller에서 인증과 인가를 수행해야 한다.
-
Service 로직은 비즈니스 로직에 대한 처리만 존재해야 한다.
-
Service로직 안 매서드는 하나의 역할만 수행해야 한다.
