🛠️일정 관리하기 트러블 슈팅

1. 어노테이션을 붙였는데 검증이 안 됨

• 원인 : @Valid의 위치 오류
• 증상: DTO에 @NotBlank 등을 썼지만 그냥 통과됨.
• 해결: @Valid는 반드시 검증 대상인 @RequestBody 바로 옆에 붙어야 한다.. (매개변수가 여러 개일 때 특히 주의!)
  
  

수정하기 전 코드

@PatchMapping("/{id}")
public ResponseEntity<UpdateScheduleResponseDto> updateSchedule(@Valid @PathVariable Long id, @RequestBody UpdateScheduleRequestDto requestDto, HttpSession session) {

	SessionUser sessionUser = (SessionUser) session.getAttribute("sessionUser");

	if(sessionUser == null) {
		throw new IllegalArgumentException("로그인이 필요합니다.");
	}

	UpdateScheduleResponseDto responseDto = scheduleService.updateSchedule(id, requestDto, sessionUser.getId());
	return ResponseEntity.status(HttpStatus.OK).body(responseDto);
    }

수정한 코드

@PatchMapping("/{id}")
public ResponseEntity<UpdateScheduleResponseDto> updateSchedule(@PathVariable Long id, @Valid @RequestBody UpdateScheduleRequestDto requestDto, HttpSession session) {

	SessionUser sessionUser = (SessionUser) session.getAttribute("sessionUser");

	if(sessionUser == null) {
		throw new IllegalArgumentException("로그인이 필요합니다.");
	}

	UpdateScheduleResponseDto responseDto = scheduleService.updateSchedule(id, requestDto, sessionUser.getId());
	return ResponseEntity.status(HttpStatus.OK).body(responseDto);
    }

2. 400 에러는 뜨는데 에러 메시지가 안 보임.

• 상황: 포스트맨 응답에 status: 400은 찍히는데, 내가 적은 message = "이름은 한글로..."가 안 보임.

• 해결: *GlobalExceptionHandler를 만들어 MethodArgumentNotValidException을 가로채야 합니다.
  - 스프링은 검증 오류 발생 시 상세 내용을 BindingResult(메모장)에 담아두기만 할 뿐, 자동으로 바디에 넣어주지 않기 때문입니다.

  • 비유
    보안 요원이 검사를 하다가 "어? 이름이 한글이 아니네? 하고 자기 메모장(BindingResult)에 적는다.
    - userName : 한글 아님
    그러고 나서 클라이언트에게는 너 조건이 안 맞아 하고 400에러만 보여준다.

    왜 메모장에 담아두고 안 보여주는 걸까?
    보안 때문이다. 내러 에러 정보를 너무 상세하게 보여주는 해킹의 실마리가 될 수 있기 때문이다. 또한 개발자 마다 에러를 보여주고 싶은 형식이 다르다. 어떤 사람은 한국말로 어떤 사람은 JSON으로 어떤 사람은 알림창으로 보여주고 싶어하기 때문에 스프링은 메모장에 다 모아둘 테니 보여지는 방법은 네가 정해라고 권한을 넘기는 거다.

• 핵심 코드: e.getBindingResult().getAllErrors().get(0).getDefaultMessage()를 통해 내가 설정한 메시지만 쏙 뽑아서 리턴!
  
  

추가한 코드

// 2. @Valid 어노테이션 검증 실패 에러 잡기 (@Pattern, @NotBlank 등)
@ExceptionHandler(MethodArgumentNotValidException.class)
public ResponseEntity<String> handleValidationException(MethodArgumentNotValidException e) {
	// 어노테이션에 적어둔 message만 쏙 뽑아서 반환
	// 1. 보안 요원의 장부를 연다 (getBindingResult)
	// 2. 적혀있는 에러들 중 첫 번째를 꺼낸다 (getAllErrors().get(0))
	// 3. 거기에 적힌 메시지를 읽어서 알려준다 (getDefaultMessage())
	String message = e.getBindingResult().getAllErrors().get(0).getDefaultMessage();
	return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(message);
    }

3. 왜 @NotBlank가 비번 일치 확인은 안 해줌?

• 상황: @NotBlank를 써도 DB의 비번과 대조하지 못한다.

• 이유: Bean Validation(@어노테이션)은 형식(Format) 검증만 담당한다. (비었는가? 숫자인가? 길이는?)

• 해결: 논리(Logic) 검증은 서비스 계층에서 해야 한다.

  • 중복 이메일 체크: userRepository.existsByEmail() (DB 조회 필요)

  • 비밀번호 일치 확인: user.getPassword().equals(input) (비즈니스 로직)

4. Schedule 엔티티안에 user 필드는 ok 근데 User 엔티티 안에 id라는 필드가 없다고 에러 발생*

• 상황 : No property 'id' found for type 'User'; Traversed path: Schedule.user 발생

• 원인 : ScheduleRepository에 findAllByUser_id 메서드 추가 후 JPA가 Schedule엔티티 안에 user 필드까지 찾았는데 User엔티티안에 id라는 필드가 없어 라고 에러 발생

• 해결 : 메서드명 수정 User엔티티의 필드명이 userId이기 때문에 레포지토리 메서드 명도 그에 맞춰 대문자까지 정확히 적어줌.

  • 잘못된 예 : findAllByUserid(User안에 필드명이 Id로 찾음)
  • 올바른 예 : findAllByUser_userId(User안에 필드명 userId로 찾음)

수정 전 코드

public interface ScheduleRepository extends JpaRepository<Schedule, Long> {
    List<Schedule> findAllByUserid(Long sessionUserId);
}

수정한 코드

public interface ScheduleRepository extends JpaRepository<Schedule, Long> {
    List<Schedule> findAllByUser_userId(Long sessionUserId);
}

메서드명을 맞춰야 하는 이유
JPA의 Query Method 규칙 때문이다.
findAllBy + User(필드명) + UserId(User엔티티 내부의 필드명) 조합으로 이름을 지어야 하는데, 이 중 하나라도 철자가 틀리거나 엔티티에 없는 필드명을 쓰면 애플리케이션이 실행될 때 쿼리를 못 만든다고 뻐긴다.

5. 유저 삭제 후 로그인 유지되는 오류 발생

• 상황 : 유저를 삭제했는데 쿠키에 세션ID가 남아서 로그인이 유지되는 상황 발생

• 이유 : DB와 세션/쿠키의 생명주기가 서로 다르기 때문에

  1. DB 삭제 : userRepository.delete()를 호출하면 DB에서 유저는 사라진다.
     
     
  2. 세션 생존 : 하지만 서버의 메모리(HttpSession)에는 여전히 "이 브라우저는 로그인된 사용자"라는 정보(sessionUser)가 남아있다.
     
     
  3. 검증 오류 : 이후 요청이 들어오면 서버는 DB를 확인하지 않고 세션 값이 있는지만 체크한다. 세션에는 정보가 아직 있기 때문에 로그인이 되어있다고 판단하고 유저 조회를 허용해 버린다.

• 해결 : 삭제할 때 세션도 같이 삭제
  
  

수정 전 코드

@DeleteMapping("/{id}")
public ResponseEntity<Void> deleteUser(@Valid @PathVariable Long id, @RequestBody DeleteUserRequestDto deleteUserRequestDto, HttpSession session) {
	SessionUser sessionUser = (SessionUser) session.getAttribute("sessionUser");

        if(sessionUser == null) {
            throw new IllegalArgumentException("로그인이 필요합니다.");
        }

        userService.delete(id, deleteUserRequestDto, sessionUser.getId());

        session.invalidate();
        return ResponseEntity.status(HttpStatus.NO_CONTENT).build();
    }

수정한 코드

@DeleteMapping("/{id}")
public ResponseEntity<Void> deleteUser(@Valid @PathVariable Long id, @RequestBody DeleteUserRequestDto deleteUserRequestDto, HttpSession session) {
	SessionUser sessionUser = (SessionUser) session.getAttribute("sessionUser");

	if(sessionUser == null) {
		throw new IllegalArgumentException("로그인이 필요합니다.");
	}

	userService.delete(id, deleteUserRequestDto, sessionUser.getId());

	session.invalidate();
	return ResponseEntity.status(HttpStatus.NO_CONTENT).build();
}

6. session.invalidate()의 잘못된 위치

• 상황 : 세션을 무효화하는 로직이 있지만 실제로 유저를 성공적으로 삭제할 때 세션 무효화가 되지 않는 상황 발생
• 원인 : existsById가 true를 반환하고 !가 붙어 있어 false가 되니 if문 안의 session.invalidate()는 실행되지 않고 그냥 통과. 그 후 userService.delete로 DB에서 유저만 지우고 응답을 보내버려서 세션은 그대로 살아있는 상황 발생
• 해결 : 진짜 유저 삭제가 일어나는 userService.delete(id, ...) 이 부분에서 삭제됨과 동시에 세션을 날려버린다.

수정 전 코드

@DeleteMapping("/{id}")

public ResponseEntity<Void> deleteUser(@PathVariable Long id, @RequestBody DeleteUserRequestDto deleteUserRequestDto, HttpSession session) {
	SessionUser sessionUser = (SessionUser) session.getAttribute("sessionUser");
	if(sessionUser == null) {
		throw new IllegalArgumentException("로그인이 필요합니다.");
	}
	if(!userRepository.existsById(sessionUser.getId())) {
		session.invalidate();
	} 
	userService.delete(id, deleteUserRequestDto, sessionUser.getId());
	return ResponseEntity.status(HttpStatus.NO_CONTENT).build();
}

수정 후 코드

@DeleteMapping("/{id}")
public ResponseEntity<Void> deleteUser(@Valid @PathVariable Long id, @RequestBody DeleteUserRequestDto deleteUserRequestDto, HttpSession session) {
	SessionUser sessionUser = (SessionUser) session.getAttribute("sessionUser");

	if(sessionUser == null) {
		throw new IllegalArgumentException("로그인이 필요합니다.");
	}

	userService.delete(id, deleteUserRequestDto, sessionUser.getId());

	session.invalidate();
	return ResponseEntity.status(HttpStatus.NO_CONTENT).build();
}