그럴려면 깃허브의 api를 호출해야할 필요가 있고, repo를 등록할 때 유효성을 먼저 검증하도록 하겠다.

주로 api를 스프링에서 호출할 때 사용하는 방식으로는

주로 RestTemplate와 WebClinet를 이용한 방법이 있는데 RestTemplate의 경우 현재 maintenance모드(더 이상 기능추가가 안된다)이기 때문에 계속해서 기능및 관리가 되는 WebClinet를 사용하기로 했다.

WebClinet를 사용하려면 webflux 의존성을 먼저 추가해줘야한다.

implementation 'org.springframework.boot:spring-boot-starter-webflux'

를 gradle에 추가하여 의존성을 받아준다.

API를 호출하게 되면 코드도 비동기성 성질을 띄게 만드는것이 시간이나 관점측면에서 매우 효율적인데 webflux를 이용하여 reactive 프로그래밍을 사용할 수 있게되고 그러한 비동기 시퀀스들을 사용할 수 있게 만들어주는게 webflux의 Mono와 Flux이다

여기서는 Mono 객체를 사용하도록 하겠다.

아래는 트러블슈팅의 과정이므로 완성코드는 맨 아래에 위치해있으니 조심!

@RestController
@RequestMapping("api/github")
@RequiredArgsConstructor
public class GithubRepositoryInfoController {

    private final GithubRepositoryInfoService githubRepositoryInfoService;

    @Auth
    @PostMapping
    public Response<GithubRepositoryInfoCreate> createGithubRepositoryInfo(@RequestBody GithubRepositoryInfoCreate request) {
        return Api.success(200, "깃헙 레포 등록 완료", githubRepositoryInfoService.createGitHubRepositoryInfo(request));
    }

}

먼저 컨트롤러를 만들고,

    @Transactional
    public GithubRepositoryInfoCreate createGitHubRepositoryInfo(GithubRepositoryInfoCreate request) {
        Mono<String> apiResponse = webClient.get()
                .uri(API_URL + "/repos/{owner}/{repo}", request.owner(), request.repo())
                .headers(header -> header.setBearerAuth(request.token()))
                .retrieve()
                .bodyToMono(String.class)
                .onErrorMap((e) -> {
                    throw new CustomException(ExtendApiException.BAD_REQUEST_INFO);
                });

        apiResponse
                .flatMap(response -> {
                    if (response == null || response.trim().isEmpty()) {
                        return Mono.error(new CustomException(ExtendApiException.BAD_REQUEST_INFO));
                    }
                    return Mono.empty();
                })
                .subscribe(
                        success -> {
                        },
                        error -> {
                            throw new CustomException(ExtendApiException.BAD_REQUEST_INFO);
                        }
                );

        GithubRepositoryInfo githubRepositoryInfo = GithubRepositoryInfo.createEntity(request.owner(), request.repo(), request.token());
        repositoryInfoRepository.save(githubRepositoryInfo);

        return new GithubRepositoryInfoCreate(githubRepositoryInfo.getOwner(), githubRepositoryInfo.getRepo(), githubRepositoryInfo.getToken());
    }

서비스를 만들었다. 직접 코드를 실행해보니 저장도 잘되고 코드도 잘 실행되는거같았다.

유효성 검증을 위해 일부러 맞지않는 값을 넣었는데..

콘솔에는 예외가 찍히나

실제 코드 동작은 예외가 캐치되지않고 끝까지 코드가 실행되었다.

왜그랬을까를 생각해보니 Mono로 선언한 부분은 비동기로 코드가 실행됨에 따라 다음 코드들이 github api 호출에 대한 결과값을 기다리지않고 실행되는것이였다.

그러다보니 메서드가 객체를 반환 할 때 reactive 스트림의 실행결과를 기다리지 않아 수정할 필요가 생겼다.

이에따라 컨트롤러부터 Mono타입을 반환하게 변경하였다. 그리고 Api 호출이 끝나기를 대기하고 코드를 실행하도록 변경하였다.

@RestController
@RequestMapping("api/github")
@RequiredArgsConstructor
public class GithubRepositoryInfoController {

    private final GithubRepositoryInfoService githubRepositoryInfoService;

    @Auth
    @PostMapping
    public Mono<Response<GithubRepositoryInfoCreate>> createGithubRepositoryInfo(@RequestBody GithubRepositoryInfoCreate request) {
        return githubRepositoryInfoService.createGitHubRepositoryInfo(request)
                .map(result -> Api.success(200, "깃헙 정보 생성 완료", result));
    }

}

서비스코드도 변경된 리턴값에 따라 수정하여

 @Transactional
    public Mono<GithubRepositoryInfoCreate> createGitHubRepositoryInfo(GithubRepositoryInfoCreate request) {
        return webClient.get()
                .uri(API_URL + "/repos/{owner}/{repo}", request.owner(), request.repo())
                .headers(header -> header.setBearerAuth(request.token()))
                .retrieve()
                .bodyToMono(String.class)
                .flatMap(response -> {
                    if (response == null || response.isEmpty()) {
                        return Mono.error(new CustomException(ExtendApiException.BAD_REQUEST_INFO));
                    }
                    GithubRepositoryInfo githubRepositoryInfo = GithubRepositoryInfo.createEntity(request.owner(), request.repo(), request.token());
                    return Mono.fromCallable(() -> repositoryInfoRepository.save(githubRepositoryInfo))
                            .subscribeOn(Schedulers.boundedElastic())
                            .map(savedInfo -> new GithubRepositoryInfoCreate(savedInfo.getOwner(), savedInfo.getRepo(), savedInfo.getToken()));
                })
                .onErrorMap((e) -> {
                    throw new CustomException(ExtendApiException.BAD_REQUEST_INFO);
                });

    }

이와같은 최종코드가 나오게되었다.

이전에 만든 메서드가 있긴있지만 해당 메서드는 여러번 dto가 재사용될 때 유효성 검증 항목이 상이할 때만 사용하고 일반적으론 편하게 Spring Validation을 쓰도록 하겠다.

먼저 의존성을 받아준다

build.gradle

implementation 'org.springframework.boot:spring-boot-starter-validation'

그리고 사용할 dto나 파일에 가서 붙여준다

public record CreateReq(
        @NotBlank(message = "부서명은 빈 값일 수 없습니다.") String name,
        @NotBlank(message = "부서설명은 빈 값일 수 없습니다.") String description,
        @NotNull(message = "부서장을 선택해주세요.") Long managerUserId,
        String tel
) {
}

가장 많이 사용하는게 @NotNull, @NotEmpty, @NotBlank 이렇게 세가지이다.

서로 역할이 조금씩 다르므로 주의하도록 한다. @NotNull: Null값만 검증 실패 @NotEmpty: Null과 "" 빈 문자열만 검증 실패 @NotBlank: Null과 ""및 " "와 같이 공백문자만 존재하는 문자열도 검증 실패

여기서 NotEmpty, NotBlank는 검증하는 "" 자체가 이미 문자열이므로 문자열타입에만 적용 가능한 검증이다.

그 외 타입에서 null검사를 하고싶으면 @NotNull을 사용하자

그리고 컨트롤러에 가서

@Auth
    @PostMapping
    public Response<DepartmentResp> createDepartment(@RequestBody @Valid CreateReq createReq) {
        return Api.success(200, "부서 생성 완료", departmentService.createDepartment(createReq));
    }

@Valid 라는 어노테이션을 인자로 받을 dto앞에 붙여주면 끝






진짜 끝일까?

한번 실제로 api를 호출해보면 이와같이 정돈되지않은 에러메시지가 그대로 노출이 되어버리는데 Spring Validation에서 잡힌 Exception도 advice에서 따로 처리를 해줘야한다.

  @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<Response<Map<String, String>>> handleMethodArgumentNotValidException(MethodArgumentNotValidException e) {
        Map<String, String> errors = new HashMap<>();
        List<FieldError> fieldErrors = e.getBindingResult().getFieldErrors();
        for (FieldError fieldError : fieldErrors) {
            errors.put(fieldError.getField(), fieldError.getDefaultMessage());
        }
        Response<Map<String, String>> errorResponse = Api.error(HttpStatus.BAD_REQUEST, "유효성 검증에 실패하였습니다.", errors);
        return new ResponseEntity<>(errorResponse, HttpStatus.BAD_REQUEST);

    }

나는 이런느낌으로 만들었다. MethodArgumentNotValidException에서 유효성 검증이 실패한 필드와 해당 메시지는 List fieldErrors = e.getBindingResult().getFieldErrors(); List를 만들어 가져 올 수 있고 각 인덱스마다 getField()와 getDefaultMessage() 로 꺼내서 쓸 수 있다.

그럼 다시 API를 호출해보자

이제 원하는대로 잘 나온다. 프론트 개발자 입장에선 key을 통해 컴포넌트를 참조해서 에러이벤트를 화면에 띄어주면 될 거 같다.

아마 실제 개발환경이였다면 http status를 400이 아닌 999같이 커스텀해서 유효성 검증용 에러코드로 전달해드렸을듯..?

그래서 유틸메서드로 하나 만들어서 사용하도록 해보겠다.

    public static boolean areFieldsNotNullOrEmpty(Object obj, String... fields) {
        try {
            for (String field : fields) {
                Field field1 = obj.getClass().getDeclaredField(field);
                field1.setAccessible(true);
                Object value = field1.get(obj);
                if (value == null) {
                    return false;
                }
                if (value instanceof String && ((String) value).trim().isEmpty()) {
                    return false;
                }

            }
        } catch (NoSuchFieldException | IllegalAccessException e) {
            throw new RuntimeException(e);
        }
        return true;
    }

이것이 null 값이나 빈칸에 대한 검증 메서드이다.

자바 Reflection을 사용하여 만들었으며 필드 이름을 문자열로 여러개를 받아 하나하나 검증하는 메서드이다. obj.getClass().getDeclaredField(fieldName)를 통해 obj 안에 해당 메서드 이름이 존재하면 null 값을 체크하고, 이름 자체가 존재하지 않는 메서드라면 catch로 넘어가게 된다.

이는 서버개발자의 실수일 경우가 대다수라 runtimeException으로 빼고 해당 예외는 advice를 통해 500에러로 빠진다.

아무튼 실제 사용 예시를 보면

if(!Api.areFieldsNotNullOrEmpty(patchUserReq, "email", "fullName", "phoneNumber")) {
            throw new CustomException(UserException.BAD_REQUEST_PATCH);
        }

이런식으로 사용할 수 있다. 이렇게 해두면 null 값 검증이 필요한 필드만 예외처리를 따로 할 수 있어 간편하게 사용할 수 있을 것 같다.

유저 api는

1. 회원관리 (회원 등록, 조회, 수정, 삭제)

일단 이정도가 있고 현 시점에서 user <-> userProfile 테이블만 조인하면 된다. 조인같은경우 jpa의 entity끼리만 묶고 물리db에선 제외할것이다.

userProfile.class

@Column(name = "user_id", nullable = false)
    private Long userId;

기존에 작성된 이 컬럼을

@JoinColumn(name = "user_id", nullable = false)
    @ManyToOne(fetch = FetchType.LAZY)
    private User user;

이렇게 변경해준다.

변경 후 컴파일을 돌려 QClass에 반영해주고

제일 간단한 내 정보 조회 api를 만들어보자

//UserController
    @Auth
    @GetMapping
    public Response<UserProfileResp> getCurrentUserProfile() {
        return Api.success(200, "내 정보 조회 완료", userService.getCurrentUserProfile());
    }

//UserProfileResp
@Builder
public record UserProfileResp(
        String username,
        String email,
        String role,
        String fullName,
        String phoneNumber
) {}

//UserService
    public UserProfileResp getCurrentUserProfile() {
        User user = getCurrentUser();
        return userRepository.findUserProfileByUser(user);
    }

//findUserProfileByUser Method
@Override
    public UserProfileResp findUserProfileByUser(User currentUser) {
        return jpaQueryFactory
                .select(Projections.constructor(UserProfileResp.class,
                        user.username,
                        user.email,
                        user.role,
                        userProfile.fullName,
                        userProfile.phone))
                .from(user)
                .join(userProfile).on(user.eq(userProfile.user))
                .where(
                        user.eq(currentUser)
                )
                .fetchFirst();
    }

여기서 주의해야할점은 queryDSL에 생성자 주입 방식이다. Projections.constructor는 매개변수로 (x.class, a, b, c, d, e) 를 받는데 dto 클래스 내부에 필드 순서와 쿼리에 적는 컬럼의 순서가 일치해야하고 불일치할 시 에러가 발생하므로 꼼꼼하게 체크해야한다.

결과를 보면 원하는대로 잘 나오는것을 알 수 있다.

이런 느낌으로 나머지 api도 작성해나가면 된다.

그렇다면 입맛대로 새로 만든 리스폰스 클래스도 반환타입으로 지정이 가능하다는건데 그 점에서 페이지네이션 기능이 담긴 dto를 만들어서 해당 기능이 필요할 땐 해당 클래스를 사용해 써보도록 하겠다.

먼저 dto 클래스를 하나 생성한다

SearchPageResponse.class

public record SearchPageResponse<T>(
    Long totalElements,
    Long totalPages,
    Integer currentPage,
    Integer pageSize,
    List<T> content) {}

record는 자바14쯤에서 새롭게 나온 클래스 타입인데, record 타입으로 선언하면 효율적이고 간결하게 dto 생성이 가능하다, getter, setter는 물론이고 생성자, toString같은 메서드, 그리고 불변성 보장도 해주다 보니 여러모로 유용하다

물론 lombok을 사용해도 되긴하지만 코드량을 좀 더 줄이고 간단하게 만들기위해 record로 생성했다.

다시 본론으로 와서 페이지네이션 기능은 99% 사용자의 편의성을 위해 만들어진 기능인데 이에따라 사용자와 좀 더 가까운곳에서 개발하는 프론트엔드쪽에서 활용해야한다고 생각한다.

그렇기때문에 만약 프론트엔드 개발자와 협업중이라면 서로 어떤 값들이 필요한지 문서화를 미리미리 해두는게 좋다.

여기서는 최대한 보편적인 페이지네이션 클래스로 생성하여

totalElements 에는 전체 데이터의 개수 (토탈페이지와 연관, 또는 전체 데이터개수 반환 필요할 때)

totalPages 에는 전체 페이지의 수

currentPage 는 현재 페이지

pageSize 는 페이지당 담길 개수

content 는 담겨있는 정보

정도를 넣었고 객체 생성을 위해 빌더 메서드 하나만 생성하도록 하겠다. 생성자가 자동으로 들어가서 굳이 안넣어도 되지만.. 그냥 다른곳들은 빌더로 생성을 하는데 여기만 생성자로 하면 코드가 좀 일관성 없어보여서 넣는다.

@Builder
public record SearchPageResponse<T>(
        Long totalElements,
        Long totalPages,
        Integer currentPage,
        Integer pageSize,
        List<T> content) {

    public static <T> SearchPageResponse<T> of(
            Long totalElements,
            Long totalPages,
            Integer currentPage,
            Integer pageSize,
            List<T> content
    ) {
        return SearchPageResponse.<T>builder()
                .totalElements(totalElements)
                .totalPages(totalPages)
                .currentPage(currentPage)
                .pageSize(pageSize)
                .content(content)
                .build();
    }
}

그러면 일단 이런 형태가 완성이 되는데, 원래 dto마다 전부 테스트를 돌릴 생각은 없지만 해당 dto는 앞으로도 자주 사용할 코드기에 테스트코드로 한번 돌려보자

테스트 코드

class SearchPageResponseTest {

    @Test
    void 정상_데이터_생성_테스트() {
        // Given
        Long totalElements = 100L;
        Long totalPages = 10L;
        Integer currentPage = 1;
        Integer pageSize = 10;
        List<String> content = Arrays.asList("Item1", "Item2", "Item3");

        // When
        SearchPageResponse<String> response = SearchPageResponse.of(
                totalElements,
                totalPages,
                currentPage,
                pageSize,
                content
        );

        // Then
        assertNotNull(response);
        assertEquals(totalElements, response.totalElements());
        assertEquals(totalPages, response.totalPages());
        assertEquals(currentPage, response.currentPage());
        assertEquals(pageSize, response.pageSize());
        assertEquals(content, response.content());
        assertEquals(3, response.content().size());
    }

    @Test
    void 빈_콘텐츠_생성_테스트() {
        // Given
        Long totalElements = 0L;
        Long totalPages = 0L;
        Integer currentPage = 1;
        Integer pageSize = 10;
        List<String> content = List.of();

        // When
        SearchPageResponse<String> response = SearchPageResponse.of(
                totalElements,
                totalPages,
                currentPage,
                pageSize,
                content
        );

        // Then
        assertNotNull(response);
        assertEquals(totalElements, response.totalElements());
        assertEquals(totalPages, response.totalPages());
        assertEquals(currentPage, response.currentPage());
        assertEquals(pageSize, response.pageSize());
        assertTrue(response.content().isEmpty());
    }

    @Test
    void Null_생성_테스트() {
        // When
        SearchPageResponse<String> response = SearchPageResponse.of(
                null,
                null,
                null,
                null,
                null
        );

        // Then
        assertNotNull(response);
        assertNull(response.totalElements());
        assertNull(response.totalPages());
        assertNull(response.currentPage());
        assertNull(response.pageSize());
        assertNull(response.content());
    }
}

실제 사용은 현재 프로젝트엔 없지만 예전에 했던 프로젝트 코드를 보면

controller

@Auth
    @GetMapping("memo-list")
    @Operation(summary = "메모 리스트 조회", description = "작성된 메모 리스트를 조회합니다.\n"
        + "empIdx 필드를 null로 주시면 전체 조회입니다.")
    public Response<SearchPageResponse<MemoItem.Response>> getMemoList(
        @RequestParam(name = "pageSize") Integer pageSize,
        @RequestParam(name = "pageNumber") Integer pageNumber,
        @RequestParam(name = "empIdx", required = false) Long empIdx
    ) {
        return new Response<>(HttpStatus.OK.value(), memoService.getCallMemoList(pageSize, pageNumber-1, empIdx));
    }

service

 public SearchPageResponse<MemoItem.Response> getCallMemoList(Integer pageSize, Integer pageNumber, Long empIdx) {

        Employee employee = employeeRepository.findByIdx(AuthHolder.getUserId())
            .orElseThrow(() -> new CustomException(EmployeeErrorCode.NOT_FOUND_EMPLOYEE));

        Pageable pageable = Pageable.ofSize(pageSize).withPage(pageNumber);
        List<Memo> memos = memoRepository.findMemoList(pageable, empIdx, employee);
        List<MemoItem.Response> memoItems = memos.stream()
            .map(MemoItem.Response::from)
            .toList();

        Long total = memoRepository.countMemoList(empIdx, employee);
        Long totalPage = (long)Math.ceil((double)total / pageSize);
        return SearchPageResponse.of(total, totalPage, pageNumber + 1, pageSize, memoItems);
    }

이런 느낌으로 사용하면 된다

1. 회원관리 (회원 등록, 조회, 수정, 삭제)

2. 부서 관리

3. 프로젝트 관리

4. 프로젝트 멤버 및 태스크

5. 댓글 및 파일 업로드

6. 알림 및 기타

※ 참고: 추가 설계 예정.

@AuthenticationPrincipal CustomUserDetails userDetails

를 인자로 받아 사용한다.

근데 내가 실제로 사용해봤을 땐 번거롭기도하고 코드복잡도도 올라간다고 느껴서 편리하게 사용 가능한 어노테이션을 직접 만들어보겠다.

우선 어노테이션 선언 파일을 하나 만들어준다

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Auth {

    boolean includeUserIdx() default true;

}

그리고 이 어노테이션을 사용해 데이터를 담거나 꺼내올수있는 holder를 하나 만들어줄거다

AuthHolder.class

public class AuthHolder {

    private static final ThreadLocal<Long> userIdxHolder = new ThreadLocal<>();

    public static void setUserId(Long userId) {
        userIdxHolder.set(userId);
    }

    public static Long getUserId() {
        return userIdxHolder.get();
    }

    public static void clearUserIdx() {
        userIdxHolder.remove();
    }

}

ThreadLocal을 통해 관리를 하도록 하겠다.

이제 매번 복잡한 코드를 생략하고, 인증절차를 미리 컨트롤러에 도달하기전에 미리 하기 위해 인터셉터를 만들어주자

@RequiredArgsConstructor
@Component
public class AuthInterceptor implements HandlerInterceptor {


    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {


        try{
            if (handler instanceof HandlerMethod handlerMethod) {
                Auth authAnnotation = handlerMethod.getMethodAnnotation(Auth.class);

                if (authAnnotation != null) {
                    boolean includeUserIdx = authAnnotation.includeUserIdx();
                    if (includeUserIdx) {

                        if (!request.getHeader("Authorization").startsWith("Bearer ")) {
                            throw new CustomException(UserException.HANDLE_ACCESS_DENIED);
                        }
                        String token = request.getHeader("Authorization").split(" ")[1];

                        Long userId = TokenProvider.getUserIdFromToken(token);
                        request.setAttribute("userId", userId);
                        AuthHolder.setUserId(userId);
                    }
                    return true;
                }
            }

            return HandlerInterceptor.super.preHandle(request, response, handler);
        } catch (NullPointerException e) {
            throw new CustomException(UserException.HANDLE_ACCESS_DENIED);
        }

    }

}

간단한 토큰 검증 후 TokenProvider에서 userId를 꺼내 AuthHolder에 넣어주는 코드이다.

이제 이 인터셉터를 mvcConfig에 인터셉터로 사용합니다~ 하고 명시해준다

@Configuration
@RequiredArgsConstructor
public class WebMvcConfig implements WebMvcConfigurer {

    private final AuthInterceptor authInterceptor;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(authInterceptor);
    }

}

이제 @Auth가 컨트롤러 메서드에 들어가면 이 api는 인증정보가 반드시 필요하게된다.

    @Auth
    @GetMapping("success")
    public Response<Long> hello() {
        return Api.success(200, "성공 메시지", AuthHolder.getUserId());
    }

이런 테스트용 api를 하나 만들어주고 호출해보면

실제로 /api/*/auth/* 과 상관없는 api 인데도 인증절차를 거치게 된다. 또한 성공데이터에 유저번호를 가져오는 코드를 통해 현재 로그인한 유저의 유저번호를 가져올 수 있고

비즈니스 코드에 사용할 땐 이 유저번호를 통해 유저를 db에서 조회해서 사용할 수 있다!

1. CORS, CSRF, 폼 로그인: 모두 비활성화 로컬에서만 돌릴 서버기 때문에 전부 비활성화

2. Stateless 모드로 세션 비활성화 sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) 를 통해 서버가 세션을 저장하지 않고, 매 요청마다 토큰 기반으로 인증을 처리하는 구조를 명시

3. 커스텀 TokenFilter 등록 addFilterBefore(new TokenFilter(), UsernamePasswordAuthenticationFilter.class)를 통해 이전포스트에서 생성한 Filter를 등록해준다.

4. 경로 보호 requestMatchers("/api/*/auth/*").authenticated()
   인증이 필요한 url을 명시 반면, 그 외 모든 요청은 공개(permitAll) 처럼 설정해준다.

5. 기타 추후 추가할 나머지 예외처리exceptionHandling()은 확장성 고려해 비워둔다

이제 이대로 파일을 만들어보자

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    CorsConfigurationSource corsConfigurationSource() {
        return request -> {
            CorsConfiguration config = new CorsConfiguration();
            config.setAllowedHeaders(Collections.singletonList("*"));
            config.setAllowedMethods(Collections.singletonList("*"));
            config.setAllowedOriginPatterns(Collections.singletonList("*"));
            config.setAllowCredentials(true);
            return config;
        };
    }

    @Bean
    public SecurityFilterChain securityFilterChai(HttpSecurity http) throws Exception {
        http
                .cors(cors -> cors.configurationSource(corsConfigurationSource()))
                .csrf(AbstractHttpConfigurer::disable)
                .formLogin(AbstractHttpConfigurer::disable)
                .sessionManagement(sessionManagement ->
                        sessionManagement
                                .sessionCreationPolicy(SessionCreationPolicy.STATELESS))
                .addFilterBefore(new TokenFilter(), UsernamePasswordAuthenticationFilter.class)
                .authorizeHttpRequests(
                        authorizeRequests -> authorizeRequests
                                .requestMatchers("/api/**/auth/**")
                                .authenticated()
                                .anyRequest().permitAll()
                )
                .headers(
                        httpSecurityHeadersConfigurer -> httpSecurityHeadersConfigurer
                                .frameOptions(HeadersConfigurer.FrameOptionsConfig::disable)
                )
                .exceptionHandling((exceptionConfig) -> {});

        return http.build();
    }
}

이제 진짜 거의 다왔다.

일단 현재까지 개발한 내용으로 권한 인증이 필요한 api를 테스트용으로 하나 만들어보자

인증토큰을 제대로 넣은 경우 의도한대로 동작을 하고있다. 그럼 토큰이 잘못되었거나 변조되었다면? 아니면 기간만료일경우 아무튼 토큰 유효성 검증을 통과 못한 경우엔 어떻게 될까?

에러는 뜬다.. 근데 이 에러는 우리가 이전에 만든 에러 response하고 형태가 전혀 다르다

이런 json으로 반환하는게 기대값이였는데 왜 그럴까?

Spring security 필터 단계에서 발생하는 예외는 DispatcherServlet가 호출되기 전에 발생하게 된다. 반면 저번에 만들어둔 GlobalExceptionHandler은 DispatcherServlet이 요청을 받아서 처리할 때 호출된다.

그렇기 때문에 Advice로는 해당 예외를 캐치할수가없다

흠.. 그렇다면 어떤식으로 해결하면 될까? 바로 Spring security 내부적으로 exception을 담당하는 필터를 한번 더 거치게 만들면 된다.

바로 만들어보자

public class TokenExceptionHandleFilter extends OncePerRequestFilter {

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response,
                                    FilterChain filterChain) throws
            ServletException, IOException {
        try {
            filterChain.doFilter(request, response);
        } catch (SignatureException | ExpiredJwtException e) {
            setErrorResponse(response, UserException.CANT_ACCESS);
        } catch (AccessDeniedException e) {
            setErrorResponse(response, UserException.HANDLE_ACCESS_DENIED);
        } catch (JwtException e) {
            filterChain.doFilter(request, response);
        }
    }

    private void setErrorResponse(HttpServletResponse response, Error errorCode) throws IOException {
        Response<String> exceptionResponse = new Response<>(errorCode.getStatus().value(), errorCode.getMessage());

        // 응답 상태 코드를 401로 설정 (인증 실패).
        response.setStatus(errorCode.getStatus().value());

        response.setContentType("application/json");

        response.setCharacterEncoding("utf-8");

        try (PrintWriter writer = response.getWriter()) {
            ObjectMapper objectMapper = new ObjectMapper();
            writer.write(objectMapper.writeValueAsString(exceptionResponse));
        }
    }

}

그 후 새로 만든 핸들필터를 securityConfig에 필터체인을 걸어준다

.addFilterBefore(new TokenExceptionHandleFilter(), UsernamePasswordAuthenticationFilter.class)

추가적으로 작업할 예외가 있다면 커스텀해서 security config에

.exceptionHandling((exceptionConfig) -> {});

부분에 추가하면 된다

예를들어

@Component
public class CustomAccessDeniedHandler implements AccessDeniedHandler {
    @Override
    public void handle(HttpServletRequest request, HttpServletResponse response,
                       AccessDeniedException accessDeniedException) throws IOException, ServletException {

        Response<String> exceptionResponse = new Response<>(403, "권한이 없는 메뉴에 접근하셨습니다.");

        response.setStatus(HttpServletResponse.SC_FORBIDDEN);

        response.setContentType("application/json");

        response.setCharacterEncoding("utf-8");

        try (PrintWriter writer = response.getWriter()) {
            ObjectMapper objectMapper = new ObjectMapper();
            writer.write(objectMapper.writeValueAsString(exceptionResponse));
        }
    }
}

이런 파일을 하나 생성하고 Security Config 파일에 의존성 주입을 해준 후

.exceptionHandling((exceptionConfig) -> {
                    exceptionConfig.accessDeniedHandler(accessDeniedHandler);
                });

이런식으로 추가하면 된다.

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SecurityConfig {

    private final CustomAccessDeniedHandler accessDeniedHandler;
    private final CustomAuthenticationEntryPoint authenticationEntryPoint;

    CorsConfigurationSource corsConfigurationSource() {
        return request -> {
            CorsConfiguration config = new CorsConfiguration();
            config.setAllowedHeaders(Collections.singletonList("*"));
            config.setAllowedMethods(Collections.singletonList("*"));
            config.setAllowedOriginPatterns(Collections.singletonList("*"));
            config.setAllowCredentials(true);
            return config;
        };
    }

    @Bean
    public SecurityFilterChain securityFilterChai(HttpSecurity http) throws Exception {
        http
                .cors(cors -> cors.configurationSource(corsConfigurationSource()))
                .csrf(AbstractHttpConfigurer::disable)
                .formLogin(AbstractHttpConfigurer::disable)
                .sessionManagement(sessionManagement ->
                        sessionManagement
                                .sessionCreationPolicy(SessionCreationPolicy.STATELESS))
                .addFilterBefore(new TokenExceptionHandleFilter(), UsernamePasswordAuthenticationFilter.class)
                .addFilterBefore(new TokenFilter(), UsernamePasswordAuthenticationFilter.class)
                .authorizeHttpRequests(
                        authorizeRequests -> authorizeRequests
                                .requestMatchers("/api/**/auth/**")
                                .authenticated()
                                .anyRequest().permitAll()
                )
                .headers(
                        httpSecurityHeadersConfigurer -> httpSecurityHeadersConfigurer
                                .frameOptions(HeadersConfigurer.FrameOptionsConfig::disable)
                )
                .exceptionHandling((exceptionConfig) -> {
                    exceptionConfig.accessDeniedHandler(accessDeniedHandler);
                    exceptionConfig.authenticationEntryPoint(authenticationEntryPoint);
                });

        return http.build();
    }
}

이게 완성된 내 security config 파일이다

이런 느낌으로 원하는대로 잘 떨어진다.

필터의 역할은 클라이언트가 요청할 때마다 헤더의 담긴 jwt 토큰을 읽어 유효성 검증을 통해 유효하다면 SecurityContext에 올려주고, 유효하지않다면 인증실패처리를 해주는 기능을 가지고있다.

그 후 만든 필터를 SecurityConfig 파일을 만들어 등록해주는 것 까지 해보겠다.

우선 TokenFilter.class를 만들어주자

public class TokenFilter extends OncePerRequestFilter {


    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {

    }
}

이것이 내가 만들 토큰필터의 기본 구조이다. 이제 이 필터에 매 요청시 검증하는 로직을 만들것이다.

일단 검증 단계를 설계해보자 나같은 경우는 우선

1. 헤더에 토큰 속성이 존재하는지
2. 존재한다면 Bearer 로 시작하는 정상 토큰인지
3. 만료시간이 초과된 토큰인지

이렇게 세단계를 우선 검증해볼것이다.

이 단계를 검증하려면 TokenProvider 클래스에 만료시간 체크 메서드 추가가 필요하니 그 메서드부터 만들어주자

TokenProvider.class

public static boolean isExpired(String token) {
        Date expiredDate = extractClaims(token).getExpiration();
        return expiredDate.before(new Date());
    }

그 후 앞서 말한 세가지 검증을 Filter 단에 추가해보자

@RequiredArgsConstructor
public class TokenFilter extends OncePerRequestFilter {


    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        String authorizationHeader = request.getHeader(HttpHeaders.AUTHORIZATION);

        //헤더에 토큰을 담는 속성이 없으면 비로그인으로 판단
        if (authorizationHeader == null) {
            filterChain.doFilter(request, response);
            return;
        }
        //Bearer 로 시작하는 정상 토큰인지 유효성 검사
        if (!authorizationHeader.startsWith("Bearer ")) {
            filterChain.doFilter(request,response);
            return;
        }
        String token = authorizationHeader.split(" ")[1];

        //토큰 만료시간 검사
        if (TokenProvider.isExpired(token)) {
            filterChain.doFilter(request, response);
            return;
        }
    }
}

이제 세가지 단계를 넘어간 경우 정상적으로 시스템에서 사용이 가능한 토큰임을 검증했다.

그리고 토큰에서 필요한 정보를 꺼내서 나머지 로직을 진행하면 된다.

그리고 토큰에서 필요한 정보를 꺼내쓰는 메서드를 만들고 이 때 이전에는 토큰안에 넣지않았지만 향후 권한정보가 필요할 수 있으므로 TokenProvider에서 토큰생성코드 수정과 필요한 몇가지 메서드를 만들어주자

public static String createToken(User user) {
        Date expiryDate = Date.from(
                Instant.now()
                        .plus(1, ChronoUnit.DAYS)
        );

        Claims claims = Jwts.claims();
        claims.put("id", user.getId());
        claims.put("username", user.getUsername());
        //추가 된 부분
        claims.put("role", user.getRole());

        return Jwts.builder()
                .signWith(SignatureAlgorithm.HS256, SECRET_KEY)
                .setClaims(claims)
                .setExpiration(expiryDate)
                .compact();
    }

    public static Long getUserIdFromToken(String token) {
        return extractClaims(token).get("id", Long.class);
    }

    public static String getUsernameFromToken(String token) {
        return extractClaims(token).get("username", String.class);
    }

    public static String getRoleFromToken(String token) {
        return extractClaims(token).get("role", String.class);
    }

그리고 사용자 정보를 인증객체로 생성하기 위해 UserDetails를 상속받는 클래스를 생성해주자 권한 부분은 일단 간단하게 만들고 추후 권한에 따른 설정같은게 늘어나면 기능확장을 하면 된다.

CustomUserDetails.class

@RequiredArgsConstructor
public class CustomUserDetails implements UserDetails {

    private final String userRole;

    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        Set<GrantedAuthority> authorities = new HashSet<>();
        if (userRole.equals("ADMIN")) {
            authorities.add(new SimpleGrantedAuthority("ROLE_ADMIN"));
        }

        if (userRole.equals("MEMBER")) {
            authorities.add(new SimpleGrantedAuthority("ROLE_MEMBER"));
        }

        if (userRole.equals("GUEST")) {
            authorities.add(new SimpleGrantedAuthority("ROLE_GUEST"));
        }

        return authorities;
    }

    @Override
    public String getPassword() {
        return "";
    }

    @Override
    public String getUsername() {
        return "";
    }
}

이런 느낌으로 만들어주자

그리고 UsernamePasswordAuthenticationToken 객체를 하나 생성해서 CustomUserDetails 로 만든 인증객체에 사용자 정보도 넣어 스프링 시큐리티에서 사용할 수 있게 만들어 준다.

다음으로는 요청에 대한 인증 정보를 스프링 시큐리티 컨택스트에 넣는거로 인증 인가 부분을 마무리 할 수 있다.

전체코드

public class TokenFilter extends OncePerRequestFilter {


    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        String authorizationHeader = request.getHeader(HttpHeaders.AUTHORIZATION);

        //헤더에 토큰을 담는 속성이 없으면 비로그인으로 판단
        if (authorizationHeader == null) {
            filterChain.doFilter(request, response);
            return;
        }
        //Bearer 로 시작하는 정상 토큰인지 유효성 검사
        if (!authorizationHeader.startsWith("Bearer ")) {
            filterChain.doFilter(request, response);
            return;
        }
        String token = authorizationHeader.split(" ")[1];

        //토큰 만료시간 검사
        if (TokenProvider.isExpired(token)) {
            filterChain.doFilter(request, response);
            return;
        }

        Long userId = TokenProvider.getUserIdFromToken(token);
        String username = TokenProvider.getUsernameFromToken(token);
        String role = TokenProvider.getRoleFromToken(token);

        CustomUserDetails userDetails = new CustomUserDetails(role);

        UsernamePasswordAuthenticationToken authentication = new UsernamePasswordAuthenticationToken(userDetails, null,
                userDetails.getAuthorities());

        authentication.setDetails(new WebAuthenticationDetailsSource().buildDetails(request));
        SecurityContextHolder.getContext().setAuthentication(authentication);
        filterChain.doFilter(request,response);

    }
}

요약하자면 TokenFilter 에서는 jwt 토큰의 유효성을 검증하고 검증한 후

• JWT 토큰에 담긴 사용자 정보를 바로 추출
• 그 정보를 스프링 시큐리티 인증 객체에 세팅
• 이로써 이후 요청에 대한 인증, 권한 체크가 원활히 수행됨

이러한 핵심 기능을 수행하는 단계라고 볼 수 있다.

이번 포스팅은 UserService 쪽에 로그인 메서드를 만드는 간단한 작업이다

    @Transactional
    public LoginResp login(LoginReq login) {
        User user = userRepository.findByUsername(login.getUsername())
                .orElseThrow(()->new CustomException(UserException.BAD_REQUEST_LOGIN));

        if (!passwordEncoder.matches(login.getPassword(), user.getPassword())) {
            throw new CustomException(UserException.BAD_REQUEST_LOGIN);
        }

        String token = TokenProvider.createToken(user);
        return LoginResp.from(user, token);
    }

간단한 유효성 검사와 토큰 발급이 포함된 로그인 서비스 코드이다. jpa나 쿼리사용, resp와 같은건 본인에 맞게 잘 응용해서 만들어서 사용하면 된다

이제 컨트롤러 코드를 만들어보자

@PostMapping("/login")
    public Response<LoginResp> login(@RequestBody LoginReq loginReq) {
        return Api.success(200, "success", userService.login(loginReq));
    }

여기도 별건 없다.

이제 토큰이 잘 발급되는지 실행해보면

어제 만들어둔 아이디와 비밀번호로 잘 로그인됨이 확인 되었다.

이제 다음 포스팅은 드디어 Spring security와 연동하는 부분이다.

먼저 다른 일반적인 방식과는 특이하게 UserDetailsService를 상속받지않고 구현하는것으로 포스팅을 하겠다!

우선 암호화 키를 하나 설정해준다. 다만 이 암호화 키 또한 환경변수로 둬서 노출가능성을 최소화하는 방식으로 하겠다.

실행환경에 환경변수를 설정해두고 (지금 방식은 인텔리제이에서 로컬 실행용으로만 사용하는 환경변수 설정이다)

이후 application.yml 에 명시해주고 코드에서 사용하면 된다!

이제 토큰로그인 방식으로 구현하기위해 tokenProvider 클래스를 하나 만들어준다.

@Service
public class TokenProvider {

    private static String SECRET_KEY;

    @Value("${secret-key-source}")
    public void setSecretKey(String secretKey) {
        SECRET_KEY = secretKey;
    }

    public String createToken(User user) {
        return null;
    }

    private static Claims extractClaims(String token) {
        return null;
    }

}

이게 기본 구조이다. createToken은 토큰을 만드는 메서드, extractClaims은 토큰에서 정보를 추출하는 메서드 라고보면된다.

이제 뭘 구현할지 하나씩 생각해보자 우리가 사용할 jwt 토큰에 필요한 필수정보는 유저의 식별값, 유저의 아이디, 만료기한 이정도가 될 수 있다.

쉽게 생각하면 토큰을 만들고 토큰에서 정보를 빼내올 때 어떤 정보를 나중에 사용할지 고민하면 스펙에 맞게 설계하고 코드를 작성하면 된다.

그럼 유저의 식별값과 아이디부터 해보자

식별값과 아이디의 경우 createToken 메서드에서 인자로 받는 User 객체안에 들어있을거기 때문에 간단하다.

public String createToken(User user) {

        Claims claims = Jwts.claims();
        claims.put("id", user.getId());
        claims.put("username", user.getUsername());

        return null;
    }

그리고 그 다음은 만료기한이다.

public String createToken(User user) {
        Date expiryDate = Date.from(
                Instant.now()
                        .plus(1, ChronoUnit.DAYS)
        );

        Claims claims = Jwts.claims();
        claims.put("id", user.getId());
        claims.put("username", user.getUsername());

        return null;
    }

이렇게 만들면 jwt 토큰에는 식별값, 아이디, 만료기한이 들어있게 된다. 이제 이걸 토큰 형식으로 변환해서 return 해주면된다.

public String createToken(User user) {
        Date expiryDate = Date.from(
                Instant.now()
                        .plus(1, ChronoUnit.DAYS)
        );

        Claims claims = Jwts.claims();
        claims.put("id", user.getId());
        claims.put("username", user.getUsername());

        return Jwts.builder()
                .signWith(SignatureAlgorithm.HS256, SECRET_KEY)
                .setClaims(claims)
                .setExpiration(expiryDate)
                .compact();
    }

토큰 생성부분 코드이다. 이제 이걸 테스트코드로 잘 나오는지 테스트해보자

TokenTest.class

public class TokenTest {

    private TokenProvider tokenProvider;

    @BeforeEach
    public void setUp() {
        tokenProvider = new TokenProvider();
        tokenProvider.setSecretKey("test");
    }

    @Test
    public void 토큰생성_테스트() {
        User user = User.builder()
                .id(1L)
                .username("test")
                .password("<PASSWORD>")
                .build();
        String token = tokenProvider.createToken(user);
        System.out.println(token);
    }



}

결과도 잘 나오는걸 확인 할 수 있다.

근데 토큰만 있으면 실제로 넘어간 데이터가 잘 저장됐는지 확인이 안되지않나? 그 테스트는 이제 정보를 추출할 메서드를 마저 만든 후 그 메서드를 테스트하며 확인해볼것이다.

public Claims extractClaims(String token) {
        return Jwts.parser().setSigningKey(SECRET_KEY).parseClaimsJws(token).getBody();
    }

이러한 정보추출 메서드를 만들었다. 접근제한은 테스트에서 사용하기위해 일단 public 테스트가 확인되면 다시 prvaite 으로 변경할것이다.

이제 이 코드또한 테스트코드로 돌려보자

TokenTest.class

public class TokenTest {

    private TokenProvider tokenProvider;
    private String token;
    private final User user = User.builder()
            .id(1L)
            .username("test")
            .password("<PASSWORD>")
            .build();

    @BeforeEach
    public void setUp() {
        tokenProvider = new TokenProvider();
        tokenProvider.setSecretKey("test");
        token = tokenProvider.createToken(user);
    }

    @Test
    public void 토큰정보_확인_테스트() {
        Claims claims = tokenProvider.extractClaims(token);
        assertEquals(Long.valueOf(claims.get("id").toString()), user.getId());
        assertEquals(claims.get("username").toString(), user.getUsername());
    }
}

token 생성의 선행작업을 위해 생성 테스트 코드를 BeforeEach로 위치를 변경하였다. 테스트 결과도 성공이므로 로그인했을때 정보를 담고있는 jwt 토큰을 생성하는데는 성공적이다!

먼저 이번 포스팅에 필요한 의존성이다

implementation 'org.springframework.boot:spring-boot-starter-security'
implementation group: 'io.jsonwebtoken', name: 'jjwt', version: '0.9.1'

인증 인가의 경우

상대적으로 간단하고 순서상 회원가입이 되어야하기때문에 회원가입을 먼저 개발해보자

비즈니스에 맞게 회원가입 dto를 작성해보자

내 비즈니스에서는 받아야할 정보가 username(아이디로 쓸 컬럼), email, password, role, department, full_name 이다.

부서 비즈니스는 아직 미개발이므로 그 쪽은 임시코드로 개발하도록 하겠다

@Getter
@NoArgsConstructor
@Builder
@AllArgsConstructor
public class SignUp {

    private String username;
    private String email;
    private String password;
    private String confirmPassword;
    private String role;
    private Integer department;
    private String phone;
    private String fullName;

}

이렇게 만든 SignUp Request를 우리는 User와 UserProfile로 변경해주어야한다

@Builder
    public static User SignUpToUser(SignUp signUp, String passwordEnc) {
        return User.builder()
                .username(signUp.getUsername())
                .email(signUp.getEmail())
                .password(passwordEnc)
                .role(signUp.getRole())
                .createdAt(LocalDateTime.now())
                .isDeleted(false)
                .build();
    }


        @Builder
    public static UserProfile SignUpToUserProfile(Long userId, SignUp signUp) {
        return UserProfile.builder()
                .userId(userId)
                .departmentId(signUp.getDepartment())
                .fullName(signUp.getFullName())
                .phone(signUp.getPhone())
                .build();
    }

각 엔티티에 빌더 메서드를 하나 생성해 만들어주는 코드를 작성한다.

그 다음은 드디어 서비스 코드다.

먼저 서비스단에 비즈니스 코드를 적기전에 코드를 구상해본다

회원가입에 들어가는 기능이라면

1. 아이디 중복체크
2. 비밀번호와 비밀번호 확인 체크
3. 비밀번호 암호화

간단하게 이정도 기능을 가지고 있다. 그럼 아이디 중복체크와 비밀번호 체크는 자바 코드상으로 해결하면 되고 비밀번호 암호화는 어떻게할까?

암호화의 종류는 정말 많고 복잡하다. 다만 우리가 쓰는 Spring Security 의존성에는 편리하게 사용할 수 있는 인터페이스가 미리 정의되어있어

설정파일을 통해 bean에 미리 등록해주면 의존성 주입을 받아 사용할 수 있게된다.

PasswordEncConfig.class

@Configuration
public class PasswordEncConfig {

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }

}

UserService

@Service
@RequiredArgsConstructor
public class UserService {

    private final UserRepository userRepository;
    private final UserProfileRepository userProfileRepository;
    private final PasswordEncoder passwordEncoder;

    @Transactional
    public Void createUser(SignUp signUp) {
        checkUserExist(signUp.getUsername());
        checkPasswordConfirm(signUp.getPassword(), signUp.getConfirmPassword());

        User user = userRepository.save(User.SignUpToUser(signUp, passwordEncoder.encode(signUp.getPassword())));
        userProfileRepository.save(UserProfile.SignUpToUserProfile(user.getId(), signUp));
        return null;
    }


    private void checkUserExist(String username) {
        if (!userRepository.isUsernameAvailable(username)) {
            throw new CustomException(UserException.ALREADY_EXISTS);
        }
    }

    private void checkPasswordConfirm(String password, String confirmPassword) {
        if (!password.equals(confirmPassword)) {
            throw new CustomException(UserException.MISS_MATCH_PASSWORD);
        }
    }
}

완성된 간단한 회원가입 로직이다. 음.. 특이한점은 userProfileRepository을 저장할 때 user.getId()를 바로 가져오는 형태인데

save로 먼저 저장을 하고 저장한 객체에 접근하여 데이터를 변경하여도 DB에 적용이 된다. 이는 JPA의 영속성과 관련된 부분으로 save를 통해 user를 영속성 컨테이너에 저장하여 저장된 영속 엔티티들은 DB와 동일성을 보장해주기때문에 가능한 방법이다.

또 createUser가 Void 타입을 반환하도록 되어있는데 이는 나중에 토큰을 반환하는 형식으로 변경하기 위한 임시코드이다.

이제 마지막으로 컨트롤러를 작성하러 가자

UserController.class

@RestController
@RequiredArgsConstructor
@RequestMapping("/api/user")
public class UserController {

    private final UserService userService;

    @PostMapping("/sign-up")
    public Response<Void> signUp(@RequestBody SignUp signUp) {
        return Api.success(200, "success", userService.createUser(signUp));
    }

}

컨트롤러 코드이다.

이제 서버를 실행하고 해당 api를 호출해보자

유효성 검사도 체크 해주고 이제 가입을 해보자

의도한대로 user 테이블과 userProfile 테이블에 잘 들어감을 확인했다!

이제 대망의 로그인기능을 다음에 포스팅 해보겠다

먼저 AOP가 무엇인가 부터 간단하게 설명하자면 Aspect Oriented Programming, 우리나라 말로는 관점지향 프로그래밍 정도로 불린다

그래서 이게 뭔데? 관점적으로 지향하는 프로그래밍을 어디다 쓰는건데?

이게 무슨말이냐하면 프로젝트를 개발하는 개발자의 관점을 생각해보자 이때 핵심적으로 생각해야할 관점이 존재할 것이고, 부가적으로 생각할 관점이 존재할것이다.

예를들어 비즈니스 로직, 즉 프로젝트를 개발하는 목적과 연관되며 고민을 오래하고 시간을 쏟아야하는것을 핵심적인 관점으로 바라보도록 한다면?

부가적인 관점은 메서드 시간체크, 로그스탬프, 에러처리 등은 개발자가 비즈니스 로직을 개발할 때 부가적으로 생각해야할 것들이 된다.

그렇다면 관점지향 프로그래밍을 적용하게 되면 어떻게 변할까?

쉽게말해 부가적으로 따라오는것들을 비즈니스 코드와 함께 코딩을 해야하는게 아니라 알아서 처리되도록 프로그래밍을 해두는것이 관점지향 프로그래밍을 쉽게 설명한것이 된다.

살짝 딥하게 들어가자면 스프링 빈의 생명주기에 따라 컨텍스트 내부에 외부 요청이 들어오게되면 AOP를 사용하지 않았을 때 비즈니스 로직과 함께 돌게되어 코드의 복잡성과 개발자의 피로도가 높아지지만

AOP를 사용하면 외부 요청이 들어올때 중간에 요청을 가로채서 처리할 부분을 처리해 준 후 요청이 도착하여 비즈니스 로직을 수행할 수 있다.

그럼 AOP를 사용하여 에러처리를 해보도록 하자

먼저 에러에 들어갈 내용이 담긴 인터페이스를 하나 생성해준다

Error.class

public interface Error {
    HttpStatus getStatus();
    String getMessage();
}

그리고 이 인터페이스를 상속받아주는 클래스를 하나 더 생성한다

CustomCxception.class

@Getter
public class CustomException extends RuntimeException{

    private final Error error;
    private final String errorMessage;

    public CustomException(Error error) {
        super(error.getMessage());
        this.error = error;
        this.errorMessage = error.getMessage();
    }

}

마지막으로 비즈니스나 도메인, 뭐 한곳에 몰아도 상관없지만 에러를 미리 정의해둘 ENUM 파일을 생성해준다.

SampleError.class

@Getter
@AllArgsConstructor
public enum SampleError implements Error {


    SAMPLE_ERROR(HttpStatus.BAD_REQUEST, "sample error")
    ;

    private final HttpStatus status;
    private final String message;

}

이제 준비는 끝났고, 서두에서 설명한 AOP를 사용하러 가보자

GlobalExceptionHandler.class

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(Exception.class)
    public ResponseEntity<Response<Void>> handleException(Exception e) {
        Response<Void> errorResponse = Api.error(HttpStatus.INTERNAL_SERVER_ERROR, e.getMessage());
        return new ResponseEntity<>(errorResponse, HttpStatus.INTERNAL_SERVER_ERROR);
    }

    @ExceptionHandler(CustomException.class)
    public ResponseEntity<Response<Void>> handleCustomException(CustomException e) {
        Response<Void> errorResponse = Api.error(e.getError().getStatus(), e.getMessage());
        return new ResponseEntity<>(errorResponse, e.getError().getStatus());
    }
}

@RestControllerAdvice 는 Controller단에 AOP를 적용하기위한 어노테이션이다. 나머지는 본인에 코드에 맞게 에러를 처리해주면 된다.

특이사항으로는 Exception 전체를 받는 handleException 메서드가 있는데 예외처리를 실수로 못했을 경우 500처리를 해주는 메서드라고 보면 된다.

이제 이걸 실 코드에 적용을 하면

   @GetMapping("error")
    public Response<String> error() {
        int a = 1;
        if (a == 1) {
            throw new CustomException(SampleError.SAMPLE_ERROR);
        }
        return Api.success(200, "성공 메시지", "Hello World");
    }

이렇게 간단하게 적용을 할 수 있다.

실제로 비즈니스 코드에 적용 할 때는 try/catch가 확연하게 줄어 가독성도 좋아 항상 사용하고 있다.

다만 딱 한가지 문제가 있는데 해당 기능만으로는 필터단에서 발생하는 Exception을 잡을수가 없다

예를들어 회원의 인증/인가 부분의 경우 Spring Security를 사용하게되면 대부분 Filter를 사용하여 앞단을 처리하게 될텐데 그렇게되면 요청이 들어올 때

요청 ---> 필터 ---> AOP(에러처리) ---> 컨트롤러

이런 형식으로 도달하게 된다. 그러므로 필터단에서 에러가 발생해도 내가 원하는 형태로 리스폰스를 잡아줄수가 없는데 요건 다음 포스팅에 회원 인증/인가 부분을 개발하며 함께 다뤄보겠다

먼저 내가 원하는 형식의 dto를 하나 생성한다 /dto/Response.class

@Getter
@NoArgsConstructor
@Builder
public class Response<T> {

    private String message;
    private HttpStatus code;

    @JsonInclude(JsonInclude.Include.NON_NULL)
    private T data;

    @Builder
    public Response(String message, HttpStatus code, T data) {
        this.message = message;
        this.code = code;
        this.data = data;
    }

}

첫번째 String 의 경우 응답 결과에 따른 메시지, 오류 메시지를 담는 공간 code는 HttpStatus code를 담는 공간

그리고 제일 중요한 data 변수가 응답으로 보내줄 핵심 데이터가 들어갈 공간이다. 이 경우 data 변수안에 리스트, 정수, 문자열, 튜플등 가지각색에 데이터가 들어갈 가능성이 있는 변수 공간이기에 제네릭 Type으로 지정해서 만들어줬다.

그럼 dto를 만들었으니 이 DTO를 반환시켜줄 클래스를 생성하러 가보자

/utils/Api.class

public class Api {
    public static <T> Response<T> success(HttpStatus code, String message, T data) {
        return new Response<>(message, code.value(), data);
    }

    public static <T> Response<T> success(Integer code, String message, T data) {
        return new Response<>(message, code, data);
    }

    public static <T> Response<T> error(Integer code, String message) {
        return new Response<>(message, code, null);
    }

    public static <T> Response<T> error(HttpStatus code, String message) {
        return new Response<>(message, code.value(), null);
    }

}

단순 반환 구조, code의 경우 편의성을 위해 오버로딩 메서드 하나정도 더 만들어뒀다.

이제 이렇게 만든 구조를 테스트 코드를 사용해 테스트해보자

@Test
    void 정상_반환_테스트_숫자() throws Exception {
        String message = "성공";
        Integer data = 1;
        Integer code = 200;

        Response<Integer> response = Api.success(code, message, data);
        assertNotNull(response);
        assertEquals(code, response.getCode());
        assertEquals(message, response.getMessage());
        assertEquals(data, response.getData());
    }

    @Test
    void 정상_반환_테스트_문자열() throws Exception {
        String message = "성공";
        String data = "데이터";
        Integer code = 200;

        Response<String> response = Api.success(code, message, data);
        assertNotNull(response);
        assertEquals(code, response.getCode());
        assertEquals(message, response.getMessage());
        assertEquals(data, response.getData());
    }

    @Test
    void 정상_반환_테스트_리스트() throws Exception {
        String message = "성공";
        List<Integer> data = List.of(1, 2, 3);
        Integer code = 200;

        Response<List<Integer>> response = Api.success(code, message, data);
        assertNotNull(response);
        assertEquals(code, response.getCode());
        assertEquals(message, response.getMessage());
        assertEquals(data, response.getData());
    }

    @Test
    void 정상_반환_테스트_HTTP_코드() throws Exception {
        String message = "성공";
        Integer data = 1;

        Response<Integer> response = Api.success(HttpStatus.OK, message, data);
        assertNotNull(response);
        assertEquals(HttpStatus.OK.value(), response.getCode());
        assertEquals(message, response.getMessage());
        assertEquals(data, response.getData());
    }



    @Test
    void 에러_반환_테스트() throws Exception {
        Integer code = 400;
        String message = "잘못된 요청";

        Response<Void> response = Api.error(code, message);

        assertNotNull(response);
        assertEquals(message, response.getMessage());
        assertEquals(code, response.getCode());
        assertNull(response.getData());
    }

    @Test
    public void 에러_반환_테스트_HTTP_코드() {
        String message = "서버 오류";
        Response<Void> response = Api.error(HttpStatus.INTERNAL_SERVER_ERROR, message);

        assertNotNull(response);
        assertEquals(message, response.getMessage());
        assertEquals(HttpStatus.INTERNAL_SERVER_ERROR.value(), response.getCode()); // 검증
        assertNull(response.getData());
    }

테스트 결과도 잘 나오는걸 확인 할 수 있다.

새롭게 만든 클래스를 테스트해봤으니 이제 실제 컨트롤러에 적용해서 확인을 해보도록 하겠다.

/controller/HelloworldController.class

  @RestController
@RequestMapping("/hello")
public class HelloWorldController {

    @GetMapping("")
    public Response<String> hello() {
        return Api.success(200, "성공 메시지", "Hello World");
    }

}

아주아주 간단한 컨트롤러이다. 호출해보면?

예상대로 반환값이랑 json 형태로 잘 넘어오는걸 확인할 수 있다!

다음은 에러처리를 위한 포스팅을 하겠다

그동안 써왔던 버전이기도 하고 오래동안 업데이트 된 기억이 없어 관련 자료를 찾아봤다.

제미니가 말하길 이런 취약점이 발견되었다고 하는데? 아니 그러면 이거 쓰던 사람들은 어쩌고요??

참으로 고맙게도 OpenFeign 팀에서 기존 지원 중단된 QueryDSL을 지원해주고 있다는 포스팅을 보았다.

QueryDSL 개발 중단 이후, OpenFeign QueryDSL로의 전환 배경

이 포스팅에 아주 잘 정리되어있어 읽어본 후 관련해서 OpenFeign에서 만든 QueryDSL을 찾아보니 기존에 사용하던 의존성보다 주입하는 난이도도 쉽고

무엇보다 플러그인도 따로 설치를 안해도 된다는 점에서 진입장벽이 가벼워 시도해보았다.

setting/querydsl.gradle

// querydsl.gradle
def querydslSrcDir  = layout.buildDirectory.dir("generated/querydsl").get().asFile

tasks.withType(JavaCompile).configureEach {
    options.getGeneratedSourceOutputDirectory().set(file(querydslSrcDir))
}

sourceSets {
    main {
        java {
            srcDirs += querydslSrcDir
        }
    }
}
configurations {
    querydsl.extendsFrom compileClasspath
}

./build.gradle

plugins {
    ...중략
}
def queryDslVersion = "6.11"

apply from: 'config/querydsl.gradle'

...중략

dependencies {
    ...중략
    // querydsl
    implementation("io.github.openfeign.querydsl:querydsl-core:${queryDslVersion}")
    implementation("io.github.openfeign.querydsl:querydsl-jpa:$queryDslVersion")
    annotationProcessor("io.github.openfeign.querydsl:querydsl-apt:$queryDslVersion:jpa")
    ...중략
}

이렇게 세팅해주고 compile을 돌려보면?

QClass가 아주 잘 생성됨을 확인할 수 있다!

잊기전에 포스팅하기!

그룹웨어 시스템 ERD 설계 개요

일친 시스템의 ERD를 설계해보았다. 쇠뿔도 단김에 빼라고 기획을 하니 ERD도 금방금방 나온거같다. 평소엔 좀 더 딥하고 큰 범위로 ERD를 설계했는데 이번 프로젝트의 목표 기한은 길어야 한달, 웬만하면 2주로 끝내고싶기에 최대한 간단하게 기획했다.

1. 엔티티 목록

User (회원)

• id : BIGINT (PK)
• username : VARCHAR
• email : VARCHAR
• password : VARCHAR
• role : VARCHAR
• created_at : DATETIME

User_Profile (유저 프로필)

• id : BIGINT (PK)
• user_id : BIGINT (FK, User)
• department_id : BIGINT (FK, Department)
• full_name : VARCHAR
• phone : VARCHAR

Department (부서)

• id : BIGINT (PK)
• name : VARCHAR
• description : TEXT
• user_id : BIGINT (FK, User, 부서장)
• tel : VARCHAR

Project (프로젝트)

• id : BIGINT (PK)
• owner_id : BIGINT (FK, User)
• name : VARCHAR
• description : TEXT
• webhook : TEXT
• created_at : DATETIME
• state : VARCHAR

Project_Member (프로젝트 멤버)

• id : BIGINT (PK)
• project_id : BIGINT (FK, Project)
• user_id : BIGINT (FK, User)
• role : VARCHAR
• joined_at : DATETIME

Task (업무 태스크)

• id : BIGINT (PK)
• project_id : BIGINT (FK, Project)
• assignee_id : BIGINT (FK, User)
• title : VARCHAR
• description : TEXT
• state : VARCHAR
• due_date : DATE
• created_at : DATETIME

Issue (이슈)

• id : BIGINT (PK)
• project_id : BIGINT (FK, Project)
• reporter_id : BIGINT (FK, User)
• task_id : BIGINT (FK, Task)
• pr_id : BIGINT (FK, Pull_Request)
• state : VARCHAR
• title : VARCHAR
• description : TEXT
• created_at : DATETIME
• updated_at : DATETIME

Pull_Request (PR)

• id : BIGINT (PK)
• project_id : BIGINT (FK, Project)
• title : VARCHAR
• url : VARCHAR
• status : VARCHAR
• creator_login : VARCHAR
• created_at : DATETIME

Comment (댓글)

• id : BIGINT (PK)
• content : TEXT
• target : VARCHAR — 댓글 또는 이슈, 태스크 대상 구분
• target_id : BIGINT — 대상 엔티티 ID
• created_at : DATETIME
• user_id : BIGINT (FK, User)

2. 관계 정리

• User ↔ User_Profile : 일대일 관계

• User ↔ Project : 프로젝트 소유자 (1:N)

• Project ↔ Project_Member : 다대일 관계 (프로젝트별 여러 멤버)

• User ↔ Project_Member : 다대일 (회원이 여러 프로젝...)

• Project ↔ Task : 일대다

• User (assignee) ↔ Task : 일대다

• User (reporter) ↔ Issue : 일대다

• Project ↔ Issue : 일대다

• Issue ↔ Pull_Request : 일대일 또는 다대일 (ID 연동)

• Comment ↔ 대상 (이슈, 태스크, 댓글 등) : polymorphic 형태로 대상 ID와 구분해서 저장

ERD 설계, 왜 이렇게 했을까?

• 유연성과 확장성 중심의 설계

  • 최대한 유연성과 확장성에 초점을 맞춰서 설계해보았다. 앞으로 프로젝트가 어떻게 변하든, 쉽게 대응할 수 있게 만들어 본것이다. 예를 들어, 핵심 개체들 관계는 너무 복잡하지 않게 딱 필요한 것만 딱 넣었으며, 새 기능이나 필드가 추가될 때도 어렵지 않게 고치거나 확장할 수 있게 설계하였다.

• FK 제약 최소화 및 자바 엔티티 중심 설계

  • 일단 DB에서 강제로 연관관계를 묶기보단, 자바 쪽에서 관리하는 게 훨씬 편하다. 실제로는 자바(Spring Data JPA, Hibernate 쓰는 애들)에서 데이터 무결성을 체크하게 하고, DB는 그냥 연결된 관계를 일부러 강하게 묶지 않게 되면, 물리 테이블에 저장된 정보를 수정하거나 제거할 때 제약조건에 걸리지 않아 개발 할 때 여러모로 편하고 확장성도 보장된다.

• 폴리모픽 연관 관계 고려

  • 댓글 같은 경우는 대상이 여러 가지일 수 있어서, ‘이벤트 대상이 이슈야? 태스크야? 아니면 댓글 자체야?’ 하는 문제를 해결하려고 target과 target_id라는 필드 하나로 컴팩트하게 만들어서 써보았다. 이렇게 하면 추후에 기능을 더 늘리거나 다른 대상도 쉽게 연결할 수 있음으로 따로 연관관계를 새롭게 맺지않아도 되어 확장성이 좋다!

• 외부 시스템 연동 및 연관 정보 관리

  • Pull Request(PR)는 GitHub 등 외부 시스템과 연동하는 경우가 많기 때문에, creator_login과 같이 문자열로 저장하는 방식을 선택했다 실제 유저 테이블에 저장되지 않는 정보기 때문에 문자열로 그때그때 보여주는게 나아보여서? 채택한 방식
  • 아마 추후에 필요시 별도로 깃헙 계정 연동 테이블을 만들어, 외부 계정이나 사용자 정보와 연동하는 것도 가능하도록 추가 개발해서 API 연동 시 유연성을 확보할 수 도 있을 것같다.

• PR 캐싱 전략과 데이터 일관성

  • PR 정보의 경우 깃허브에 올라간 정보를 직접 API로 불러올 예정이다. 이때 호출이 너무 잦게되면 해당 api측에서 부하가 걸릴수도, 호출 제한이 걸릴지도 모르는 일이다. 이에따라 호출을 최소화하기 위해 PR정보를 불러올 때 마다 호출하기보단 캐싱처리로 중복데이터는 서버에 저장된 데이터로 보여줄 예정이다. 다만 새로운 데이터가 있을 경우 새롭게 받아와야하는데 이 경우는 캐시 키를 뭐로 줘야할지 아직 고민중이다.

개요

• 목표: 2주~4주 내로 개발 가능한 소규모 그룹웨어 MVP 구축
• 기능 범위: 회원관리, 팀 업무 관리, 사내 협업 플랫폼, GitHub 연동 포함
• 기본 방침: 프론트엔드 미구성, 백엔드 중심 개발, 이후 확장 가능

핵심 기능 리스트

1. 회원관리

• 회원 등록, 조회, 수정, 삭제
• 로그인/로그아웃
• 역할 및 권한 부여 (관리자 / 사용자)
• 비밀번호 변경 및 프로필 관리

2. 팀 업무 관리도구

• 프로젝트/팀 생성 및 삭제
• 태스크 생성, 배정, 상태 변경 (예정/진행/완료)
• 태스크 담당자 지정
• 댓글 및 첨부파일 업로드
• 마감일 설정 및 알림 (간단한 수준)

3. 사내 협업 플랫폼

• 공지사항 게시 및 조회
• 일정 공유 또는 캘린더
• 문서 저장소 (파일 업로드/공유)
• 간단 메시지 또는 채팅

4. GitHub 연동 기능

• 프로젝트 생성 시 GitHub 저장소 또는 이슈 연동 선택
• GitHub 이슈 목록 조회
• PR 상태 조회
• 연동 정보 저장 (API 토큰 또는 OAuth 기반)

개발 전략

• 백엔드 중심로 설계 및 개발
• REST API 기반 구현
• 인증/권한 관리 포함
• 차후 프론트엔드와 연동 가능하게 설계

기대 효과

• 빠른 MVP 출시로 기본 협업 환경 마련
• 이후 필요 기능 확장 가능
• 실질 업무에 바로 활용 가능 수준의 시스템 구축

참고

최대한 짧은 시간안에 핵심 기능을 구현하는게 목표로, 그에 맞게 추가 기능의 확장성을 최대한 고려하여 개발해나갈것이다.

해당 툴을 인텔리제이에 적용하면 이런식으로 코드 품질에 대한 정보를 나타내주는데

현재 진행중인 프로젝트에서 TDD 방법론으로 개발하기로 하여 테스트 커버리지 적용을 위해 적용해보았다. 근데 문제점이 정작 우리가 궁금했던 테스트 커버리지는 제공이 안되던거였는데

문서를 아무리 뒤져도 인텔리제이 내에서 커버리지 실행하면 저것도 나와야한다고 문서에 나와있었다.

그래서 한참 삽질을 하다 선택한것이 Jacoco에서 제공해주는 코드 커버리지 보고서를 함께 사용하는 방법이였다.

일단 나는 Qodana 를 Ultmate Plus 버전을 사용중이다 2달 무료버전을 준다기에 해당 버전으로 이번 프로젝트를 진행할거같다.

로컬 실행은 대충 이정도가 끝이다. 이 상태로는 코드커버리지를 알려주지않는데 이제부터 jacoco 세팅을 시작해보겠다.

subprojects {
    apply plugin: 'jacoco'
}

먼저 build.gradle 에 jacoco 를 설정해준다. 진행중인 프로젝트 같은 경우는 멀티모듈로 되어있어 루트 프로젝트가 아닌 subproject에 공통으로 걸어줬다.

    jacoco {
        toolVersion = '0.8.10'
        setReportsDirectory(file("${rootDir}/.qodana/code-coverage"))
    }

       test {
        useJUnitPlatform()
        finalizedBy 'jacocoTestReport'
    }

    acocoTestReport {
        reports {
            xml.required = true
            html.required = false
        }
        finalizedBy 'jacocoTestCoverageVerification'
    }

    jacocoTestCoverageVerification {
        violationRules {
            rule {
                enabled = true
                element = 'CLASS'
                // includes = []

                limit {
                    counter = 'LINE'
                    value = 'COVEREDRATIO'
                    minimum = 0.00
                }

                excludes = []
            }
        }
    }

jacoco 그룹엔 버전과 저장 위치를 명시해준다. 해당 저장위치는 qodana가 코드 품질을 검사할 때 코드 검사 보고서를 읽는 위치이다.

acocoTestReport 그룹에는 qodana에서 사용할 수 있게 xml 을 허용해준다. 우리 프로젝트에선 html로 읽을 필요가 없어 html 파일도 false 로 바꿔줬다.

jacocoTestCoverageVerification 그룹에는 코드 커버리지 검사 룰인데 minimun 보다 코드 커버리지가 낮으면 빌드나 테스트를 실패시킨다.

해당 룰은 아직 미정상태로 추후 룰과 점수를 정하여 적용할 듯 싶다.

이제 ./gradlew test 를 하게되면 test - acocoTestReport - jacocoTestCoverageVerification 순으로 실행이 되어 ${rootDir}/.qodana/code-coverage 이 위치에 xml 파일이 생성이 된다.

그 후 코다나로 코드 보고서를 실행 시켜 보면

아까완 다르게 코드 커버리지가 보임을 확인 할 수 있다.

이제 로컬에선 완료했으니 git action을 통해 push 나 pr 때 사용할 수 있게 자동화해보자

name: qodana

on:
  push:
    branches:
      - develop
      - 'chore/test-coverage/#37'
  pull_request:
    branches:
      - "**"

jobs:
  qodana:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
      checks: write
    steps:
      - uses: actions/checkout@v3
        with:
          ref: ${{ github.event.pull_request.head.sha }}  # to check out the actual pull request commit, not the merge commit
          fetch-depth: 0

      - name: Set up JDK 17
        uses: actions/setup-java@v2
        with:
          java-version: '17'
          distribution: 'adopt'
          cache: 'gradle'

      - name: Validate Gradle Wrapper
        run: chmod +x ./gradlew --version
        working-directory: ./

      - name: Create code coverage folder if not exists
        run: |
          mkdir -p .qodana/code-coverage
        working-directory: ./

      - name: permission
        run: chmod +x gradlew 
        working-directory: ./

      - name: Run Tests
        run: ./gradlew test
        working-directory: ./    

      - name: Archive coverage data
        uses: actions/upload-artifact@v2
        with:
          name: gradle-coverage-data-jacoco
          path: .qodana/code-coverage

      - name: 'Qodana Scan'
        uses: JetBrains/qodana-action@v2023.2
        env:
          QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

- name: Create code coverage folder if not exists
        run: |
          mkdir -p .qodana/code-coverage
        working-directory: ./

해당 명령으로 jacoco가 실행 후 저장될 디렉토리를 미리 생성해준다.

        - name: Run Tests
        run: ./gradlew test
        working-directory: ./ 

그 후 test 를 실행하여 아까 build.gradle에 작성했던 것 처럼 test - acocoTestReport - jacocoTestCoverageVerification 순으로 실행이 될 수 있게 해준다.

      - name: Archive coverage data
        uses: actions/upload-artifact@v2
        with:
          name: gradle-coverage-data-jacoco
          path: .qodana/code-coverage

qodana scan 에서 파일을 읽을 수 있게 해당 디렉토리에 파일을 업로드 해준다.

       - name: 'Qodana Scan'
        uses: JetBrains/qodana-action@v2023.2
        env:
          QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

마지막으로 qodana scan 명령으로 qodana 스캔을 실행한다.

QODANA_TOKEN 은 Qodana.cloud 에 프로젝트를 찾아보면 찾을 수 있다. 해당 토큰을 action 키로 저장하여 action에서 변수로 사용할 수 있다.

그 후 pr을 통해 체크해보면 action이 예상대로 잘 돌아가는것을 확인 할 수 있고

내가 PR한 코드 품질에 대해 리뷰도 해준다.!!

UserDetailsService 를 상속받아 사용하는 방식이 일반적이지만 나는 사용하지않고 구현해보았다.

앞서 의존성을 받아준다

implementation 'org.springframework.boot:spring-boot-starter-security'
implementation group: 'io.jsonwebtoken', name: 'jjwt', version: '0.9.1'

testImplementation 'org.springframework.security:spring-security-test'

회원가입은 간단하다

회원가입에 request로 사용할 dto를 하나 선언해준다.

@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
@Schema(description = "회원가입 요청 DTO")
public class SignupRequest {

    @NotBlank
    @ApiModelProperty(value = "이메일 입력 필드", dataType = "String")
    private String email;
    @NotBlank
    @ApiModelProperty(value = "패스워드 입력 필드", dataType = "String")
    private String password;
    @NotBlank
    @ApiModelProperty(value = "패스워드 확인 입력 필드", dataType = "String")
    private String passwordCheck;
    @NotBlank
    @ApiModelProperty(value = "닉네임 입력 필드", dataType = "String")
    private String nickname;

    @ApiModelProperty(value = "이미지 파일 입력 필드", dataType = "MultipartFile")
    private MultipartFile profileFile;

}

    @PostMapping(value = "/signup", consumes = MediaType.MULTIPART_FORM_DATA_VALUE)
    @Operation(summary = "회원 가입 API", description = "폼데이터로 요청")
    public Response<LoginResponse> signup(@ModelAttribute SignupRequest signupRequest) {

        return ApiUtils.success(HttpStatus.CREATED, "회원 가입 성공", userService.signup(signupRequest));
    }

스펙에 따라 컨트롤러에서 요청을 받고

    private final UserRepository userRepository;
    private final PasswordEncoder passwordEncoder;

    @Transactional
    public LoginResponse signup(SignupRequest signupRequest) {
        checkDuplicateEmail(signupRequest.getEmail());
        checkConfirmPassword(signupRequest.getPassword(), signupRequest.getPasswordCheck());
        User user = User.from(signupRequest, passwordEncoder.encode(signupRequest.getPassword()));

        userRepository.save(user);
        user.setProfileUrl(uploadImageFile(signupRequest.getProfileFile(), user));
        String accessToken = TokenProvider.createToken(user);

        return LoginResponse.from(user, accessToken);
    }

   private void checkDuplicateEmail(String email) {
        if (userRepository.existsByEmail(email)) {
            throw new CustomException(UserErrorCode.DUPLICATE_USER_ID);
        }
    }

   private void checkConfirmPassword(String password, String passwordCheck) {
        if (!password.equals(passwordCheck)) {
            throw new CustomException(UserErrorCode.NOT_MATCH_PASSWORD_CONFIRM);
        }
    }

일반적인 회원가입이다. 한가지 짚어보고 넘어갈 부분은

userRepository.save(user);
user.setProfileUrl(uploadImageFile(signupRequest.getProfileFile(), user));

이 부분

save로 먼저 저장을 하고 저장한 객체에 접근하여 데이터를 변경하여도 DB에 적용이 된다. 이는 JPA의 영속성과 관련된 부분으로 save를 통해 user를 영속성 컨테이너에 저장하여 저장된 영속 엔티티들은 DB와 동일성을 보장해준다.

그 후 로그인 로직을 처리해보도록 하자

먼저 jwt 방식의 토큰 로그인을 구현하기 위해 TokenPorvider 클래스를 생성한다

@Service
public class TokenProvider {

    private static String SECRET_KEY;

    @Value("${secret-key-source}")
    public void setKey(String value) {
        SECRET_KEY = value;
    }

    public static String createToken(User user) {
        Date expiryDate = Date.from(
                Instant.now()
                        .plus(1, ChronoUnit.DAYS)
        );

        Claims claims = Jwts.claims();
        claims.put("userId", user.getId());
        claims.put("userEmail", user.getEmail());

        return Jwts.builder()
                .signWith(SignatureAlgorithm.HS256, SECRET_KEY)
                .setClaims(claims)
                .setExpiration(expiryDate)
                .compact();
    }

    // Claims에서 loginId 꺼내기
    public static String getUserEmail(String token) {
        return extractClaims(token).get("userEmail").toString();
    }

    public static Long getUserId(String token) {
        return Long.valueOf(extractClaims(token).get("userId").toString());
    }

    // 밝급된 Token이 만료 시간이 지났는지 체크
    public static boolean isExpired(String token) {
        Date expiredDate = extractClaims(token).getExpiration();
        // Token의 만료 날짜가 지금보다 이전인지 check
        return expiredDate.before(new Date());
    }

    private static Claims extractClaims(String token) {
        return Jwts.parser().setSigningKey(SECRET_KEY).parseClaimsJws(token).getBody();
    }

}

당연히 시크릿키는 노출되면 안된다. 간단한 코드들만 있으니 서비스에 맞게 커스텀해서 사용하면 된다

왜 why? 프론트 개발자 입장에선 그게 당연~히 편하다

응답에 대한 Type Interface를 미리 정의 해두면 성공이든 실패든 예외처리가 간편하게 가능하니까

먼저 ErrorCode interface를 정의해둔다

public interface ErrorCode {

    int getCode();

    String getMessage();
}

뭐 별건 없다 단순한 인터페이스 이제 이걸 상속받을 도메인 별 ErrorEnum을 생성한다

@Getter
@AllArgsConstructor
public enum UserErrorCode implements ErrorCode {
    DUPLICATE_USER_ID(HttpStatus.CONFLICT.value(), "중복 되는 아이디 입니다."),
    NOT_MATCH_PASSWORD_CONFIRM(HttpStatus.BAD_REQUEST.value(), "비밀번호와 비밀번호 확인이 일치하지 않습니다"),
    NOT_FOUND_USER(HttpStatus.NOT_FOUND.value(), "로그인 한 유저를 찾을 수 없습니다"),
    BAD_REQUEST_PASSWORD(HttpStatus.BAD_REQUEST.value(), "로그인 정보를 다시 확인하세요"),
    HANDLE_ACCESS_DENIED(HttpStatus.FORBIDDEN.value(), "로그인이 필요합니다."),
    CANT_ACCESS(HttpStatus.UNAUTHORIZED.value(), "접근권한이 없습니다"),
    FAIL_KAKAO_LOGIN(HttpStatus.BAD_REQUEST.value(), "카카오 로그인 실패!"),
    ;

    private final int code;
    private final String message;
}

ErrorCode의 code부분을 HttpStatus로 리턴받게 할 수도 있지만 커스텀 에러코드의 사용을 생각해서 int로 선언하였다.

그럼 이렇게 생성한 ErrorCode를 실제 사용할 CustomException 파일을 만들어보자

@Getter
public class CustomException extends RuntimeException {

    private final ErrorCode errorCode;
    private final String errorMessage;

    public CustomException(ErrorCode errorCode) {
        super(errorCode.getMessage());
        this.errorCode = errorCode;
        this.errorMessage = errorCode.getMessage();
    }

}

RuntimeException 을 상속받아 생성자에 super로 넣어주면 끝!

이제 잘 만든 에러들을 미리 정의해둔 공통 응답 폼에 맞춰 aop단에 만들어보자

@RestControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(Exception.class)
    public ResponseEntity<Response> handleException(Exception e) {

        Response errorResponse = new Response(false, HttpStatus.INTERNAL_SERVER_ERROR.value(), e.getMessage(), e.getCause());

        // 에러 응답 생성
        return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR.value()).body(errorResponse);
    }

    @ExceptionHandler(CustomException.class)
    public ResponseEntity<Response> handleCustomException(CustomException e) {
        // 에러 정보를 담은 ErrorResponse 객체 생성
        Response errorResponse = new Response(false, e.getErrorCode().getCode(), e.getErrorMessage(), null);

        // 에러 응답 생성
        return ResponseEntity.status(e.getErrorCode().getCode()).body(errorResponse);
    }
}

@RestControllerAdvice 어노테이션을 붙이면 json으로 응답을 내려줄 수 있다.

@ControllerAdvice 를 사용하면 에러 페이지를 노출 시켜 줄 수 있다.

정의해둔 에러 외에 개발자의 실수로 인한 런타임 에러도 일단 잡아서 같은 응답으로 내려줘야 하기때문에 Exception.class 받는 메서드와 CustomException.class를 받는 메서드로 나누어 작성한다.

응답은 ResponseEntity로 본인이 만든 공통 폼 DTO를 반환해주면 된다.

실패케이스

성공케이스

이제 실제로 비즈니스 로직에 Error를 throw해보자

    private User validUser(Long userId) {
        return userRepository.findById(userId).orElseThrow(() -> new CustomException(UserErrorCode.NOT_FOUND_USER));
    }

아주 간단하게

throw new CustomException(ErrorCode.Error)

형식으로 지정해주면 비즈니스 로직을 타다 throw를 만나면 반환해준다.

여기까지 하면 모든 에러가 공통 처리가 되었을까?

정답은 아니다. 그 이유는 Spring security 를 이용한 로그인및 인증처리 방식에서 인증처리는 보통 컨트롤러에 실제 요청이 도달하기 전 Filter 단에서 처리가 되는 반면, AOP는 컨트롤러에 요청이 도달하기 직전에 실행이 되므로 Filter가 AOP보다 앞단에서 실행된다고 생각하면 된다.

그렇다면 인증처리와 같은 Filter 단에서 나오는 에러는 Spring security에서의 에러가 뿌려지게 되므로 내가 예상한 에러 응답과 다른 응답이 뿌려지는데

이에 대해선 순서에 맞게 로그인및 회원가입을 포스팅 한 후 작성하도록 하겠다.