팀프로젝트 진행 기록 3 ~ 4일차

처음에는 뭐라도 새로운 '기술'을 집어 넣으려고 애썼으나

현재 주어진 과제에서 요구하는 최대 목표가 주어진 마감기한을 엄수하며 필수 구현이 제대로 작동하는 것이기에

새로운 걸 계속 공부하면서 넣어가며 만들어내는 것 보다는

현재 내가 알고있는 것을 기준으로 만든 후, 시간이 남으면 공부하면서 리팩토링을 진행하는 것이 낫다고 판단했다

우리팀은 경험이 적은 사람들밖에 없었기에 더더욱 그랬다

---

새벽에 프로필 수정로직으로 끙끙대다가

아침에 다시 생각해보니 이전 방식은 구현이 불가능하다고 판단되어 다른 방식으로 구현하기로 했다

 

내가 어제 생각했던 구조는 아래와 같다

1. 한 페이지에 구역이 나뉘어 프로필 수정을 진행하는 경우:

비밀번호구역, 비밀번호 제외 구역

2. 한 페이지에 고치고 싶은 정보를만 입력 후 진행하는 경우(기존 비밀번호는 제외) :

비밀번호 확인이 필요할 때 나중에 진행

 

각각의 문제점

1번은 Dto 를 따로 받아서 진행해야 하는 점

2번은 현재의 비밀번호를 따로 확인해야 하는 것이었다

 

그래서 새로 생각한 세 번째 방법

2번 처럼 한 페이지에 수정하고 싶은 사항을 두고

비밀번호를 수정하고자 하는 경우, 기존 비밀번호도 함께 입력하는 것이다

 

따라서 서버 입장에서 생각해보면

새 비밀번호 필드가 채워져 있으면 기존 비밀번호 필드도 함께 채워져 있어야만 진행하는 것이다

이렇게 하면 API도 하나만 사용할 수 있게 된다

 

// 둘 다 채워져 있는 경우 - 체크 후 비밀번호 수정 로직 진행
// 둘 중 하나만 채워져 있는 경우 - 나머지만 수정 진행 vs. 입력 안내 (바꾸실 비밀번호를 입력해 주세요 / 기존 비밀번호를 입력해주세요)
// 둘 다 비워져 있는 경우 - 나머지만 수정 진행

 

조건별 진행 방식

if (newPW != null && oldPW != null)
if (newPW != null && oldPW == null) 
if (newPW == null && oldPW != null)

 

세 가지 모두 if 문으로 처리후 나머지 필드값을 처리하기로 했다

 

그다음 해결해야만 하는 문제가 생겼는데,

사용자가 입력한 Dto 필드 값 일부가 null일 때,

기존 값이 null로 교체되지 않도록 하고, null이 아닌 값만 수정(update) 되도록 해야하는 것이다

 

(그 과정에서 PutMapping 보다는 PatchiMapping 이 더 적합하다는 것을 알게되어 수정하였다)

 

마저 구현하던 도중

Non-static method 'update' cannot be referenced from a static context 라는 오류를 만났다

찾아본 곳들에서는 생성자를 따로 만들면 된다는 등의 글들이 있었다

내가 만든 코드는 이미 선언된 user 를 가져와서 update 하려고 하는 것이라 상관 없다고 여기며 두 시간쯤 헤맸다

그러다 안되겠다 싶어 도움을 요청했는데

알고보니 변수가 아니라 클래스에서 메서드를 가져오려고 시도한 사소한 실수였다

남에게 아직 많이 초보라는 것을 증명해버렸다

아무튼 앞서 찾아본 자료의 핵심은 통하는 실수였다는 것과 그걸 눈치채지 못한 것이 놀라웠다

---

 

Optional을 이용해서 필드값이 모두 null인 경우(사용자 입력값이 하나도 없는 상태에 수정을 하고자 하는 경우)

사용자에게 입력값이 없다는 것을 알리고 싶어서

Optional 에 대해 구글링해보기도 하고 IntelliJ 자체 Optional 사용법을 확인했는데 원하는 것을 찾지 못했다

그러던 중 마침 반가운 동료분들이 오셨길래 여쭤보았고, 도움을 받았다

 

처음에는 Optional로 같이 시도해보았으나 잘 되지 않아 방향을 틀었다

RequestDto 의 각 필드값을 요소로 갖는 배열을 for 문으로 돌려서 null 인지 체크하는 코드였다

log 기능을 직접 제대로 사용해보는 것이 처음이어서 좋았다

낯설었던 log 가 살짝 친숙해진 것 같다

---

리팩토링을 진행하기 위해서 기존에 만들어 둔 조회기능을 쳐다봤는데

갑자기 Dto의 기능에 대해서 의문/혼란이 생겼다

public ResponseEntity<ProfileResponseDto> showProfile(ProfileRequestDto requestDto, User user)

 

UserDetails 를 설정하기 전에 User 로 mock up을 해 둔 상태이고

RequestDto 를 통해서 받은 정보들로 확인해서 프로필을 보여주는 메서드를 만들었었는데,

 

Dto 에 담기는 내용이 userId 와 password 인 부분에서 마음에 걸렸다

Dto 는 유저가 직접 입력한 값을 가지고 오는 내용이어야 하는데

단순 조회를 위해서는 딱히 입력하는 값이 없는 것이다

 

그렇다면 Dto 는 필요없고 UserDetails만 있으면 되는 상황 아닌가?

그런데 어제 튜터님께서 메서드 코드 작성하기 전 보시곤 플로우가 맞다고 하셨었다

 

도대체 어떤게 맞는거지?

플로우가 맞다는 말에 다른 의미가 들어 있는 걸까?

 

해결

"프로필 조회" 자체의 의미를 잘못 받아들이고 있었다

로그인한 사람이 본인 프로필만 조회하는 것이 아니라,

다른 이용자의 프로필도 구경할 수 있는 것이었다

따라서 Dto는 필요하다

 

코드를 리팩토링 하려다가 전면 수정을 하게 되었다

 

User requestUser = userRepository.findByUserIdAndPassword(requestUserId, requestPassword)

에서 password가 빠지고

그에따라

String requestPassword = requestDto.getPassword();

라는 password 추출도 필요없어지고

if (!requestUserId.equals(user.getUserId())) {
    return ResponseEntity.status(HttpStatus.UNAUTHORIZED).build();
}

 

조회 요청 들어온 user 와 로그인한 user 가 동일한지 확인을 위한 이 메서드도 필요가 없어졌다 

 

---

 

이번 과제의 핵심이 Security 이기때문에 어떤 메서드를 작성하든 JWT 인증, 인가 기능이 필수이다

그래서 사실 이미 만든 프로필 조회나 수정 메서드도 완성된 것이 아니라 할 수 있는 상태

 

그렇기 때문에 Security 기능을 먼저 완성하기로 마음 먹었다

 

jwt.secret.key 를 직접 만들 수 있는지 조사하던 중 잘 작성된 글을 발견해 여기에 남긴다

https://mgyo.tistory.com/826

JWT 직접 만들어보며 이해하기

 

https://mgyo.tistory.com/828

세션 기반 인증과 토큰 기반 인증(feat. Authentication 과 Authorization)

 

---

JwtAuthenticationFilter 클래스는 UsernamePasswordAuthenticationFilter 의 상속을 받는데

내가 원하는 건 userId 와 password 로 유저를 찾는 것이었기에 수정이 불가피했다

왜냐하면 username 은 추후 프로필에서 수정이 가능한 필드값으로 설정되어 있었기 때문이다

 

반쯤 변경했을 때, 팀원이 이미 변경해 놓았다고 하는 소식을 접했고, Git 을 통해 바로 공유했다

그 팀원분은 아직 맡은 부분을 덜 하셔서 나머지 security를 내가 진행해 보기로 했다

그렇게 Refresh 토큰 작업을 맡게 되었다

 

Refresh 토큰

 

담당 매니저님께서 이른 오후에 들르셨고

저녁에는 우리팀을 전담하시는 튜터님께서도 진행상황을 체크하러 들르셨다

그리고 진척도와 남은 기간, 주말이 껴있는 점 등을 미루어 보아

필수구현 기능 중에서도 보여지는 부분을 우선적으로 만드는게 나을 것 같다는 판단을 내려주셨고

우리팀은 그렇게 하기로 했다