목차
- 비밀번호의 무효화
- entity, dto의 제약조건은 왜 오류가 다를까?
- BeakjoonHub 사용법
1. 비밀번호의 무효화
- User/entity에 제약 조건을 걸었는데 비밀번호가 8자리 미만으로 입력을 하여도 통과가 되는 경우가 발생했다.
- 이유가 뭐니 찾아보니 우리는 암호화를 작성 하였는데 Service에서 그 암호화를 거쳐가다 보니 비밀번호가 암호화된 상태로 통과를 하는 것이다. 그러니까 무조건 20자는 족히 넘어갈 것이다.
1. 해결 방법
- 따라서 해결 방법은 entity가 아닌 dto에 제약 조건을 걸어 해결 했다.
2. entity, dto의 제약조건은 왜 오류가 다를까?
- entity에 걸었을 때
-
왜 여기서는 500/ ConstraintViolationException: 으로 나올까
-
밑에는 dto에 걸었을 때
- 여기서는 400/ MethodArgumentNotValidException 으로 나온다.
2. 궁금증 해결 (help. 조용석 튜터님)
-
DTO에 @Valid를 걸면 요청 바인딩 단계(Controller 들어오기 전) 에서 검증이 실행되어 MethodArgumentNotValidException이 발생하고, 보통 클라이언트 입력 오류로 분류되어 400으로 내려간다.
-
Entity에 제약을 걸면 Repository save/flush, 트랜잭션 커밋 직전(JPA/Hibernate 영속화 단계) 에서 검증이 실행되어 ConstraintViolationException(또는 TransactionSystemException에 래핑)이 발생한다.
-
이 단계에서 터진 예외는 스프링 기본 매핑상 “요청 검증 실패”가 아니라 “서버 내부 처리/트랜잭션 실패”로 취급되기 쉬워 500(Internal Server Error) 로 보이는 경우가 많다.
-
결론: 객체가 달라서라기보다 검증이 발생하는 레이어(전 단계: Web / 후 단계: JPA) 와 예외 처리(매핑) 대상이 다르기 때문이다.
오늘 알고리즘 코드카타에 입성을 하였다.
이런 식으로 일일이 작성하고 있었는데 플로 차트 같은 조였던 현지Park 님이 추천해 주신 BeakjoonHub를 소개해 주셨다. 짱편함....
지금은 프로그래머스에서 진행 하고있는데
제출 후 채점하기를 누르면 자동으로 깃허브에 등록된다. 신세계~~
보면 "프로그래머스"라고 패키지가 생성되면서 자동으로 추가되는 모습!!
취준생